OpenVPN a pornit, dar nu a afișat nimic: verifică mai întâi log-append

Pornești OpenVPN dintr-un shell cu un fișier de configurare, iar terminalul rămâne acolo fără niciun rezultat. Fără banner, fără eroare, fără prompt. Instinctul spune că pornirea a eșuat, așa că pornești încă o copie, apoi încă una, iar mașina ajunge cu mai multe instanțe pe jumătate configurate. Înainte de toate acestea, verifică în profil o directivă care a redirecționat deja jurnalul în altă parte. Liniștea este o proprietate a consolei, nu a procesului.

Liniștea are două explicații foarte diferite

Prima este că procesul rulează bine și scrie într-un fișier pe care nu îl urmărești. A doua este că s-a încheiat imediat cu o eroare înregistrată în același fișier.

Ambele lasă un terminal gol, iar o singură întrebare le desparte: există acum un proces și ce se află în fișierul în care i s-a spus să scrie. Răspunde la asta înainte de a atinge din nou configurația. Repornirea pentru a obține rezultat este felul în care două instanțe ajung să se certe pe un singur dispozitiv de tunel și pe același port, ceea ce produce erori fără nicio legătură cu problema inițială.

Găsește directiva, apoi găsește procesul.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Găsește destinația pe care o folosește procesul care rulează

Citește profilul cu care procesul a fost de fapt pornit, nu pe cel pe care l-ai editat. O instanță administrată de un serviciu încarcă de obicei o altă cale și rulează într-un alt director de lucru, așa că un nume de fișier relativ se rezolvă undeva unde nu te așteptai.

O directivă cd explicită face această distincție mai clară, pentru că calea relativă se mută odată cu schimbarea directorului. Dacă ai moștenit această configurație, fișierul poate sta într-un loc în care nimeni nu ar căuta acum.

Compară timpul de modificare al fișierului cu momentul în care ai pornit. Un jurnal de săptămâna trecută este dovadă despre săptămâna trecută. Apoi citește ultimele rânduri ale fișierului care s-a schimbat și tratează ce este acolo ca mesajul de pornire care ți-a lipsit.

log versus log-append: dovadă și ștergere

log-append adaugă la ce se află deja în fișier. log deschide fișierul pentru scriere și îl trunchiază, așa că trecerea de la unul la altul poate șterge rularea pe care urma să o citești.

Dacă cineva a schimbat directiva în timpul depanării, dovada anterioară a dispărut deja și dimensiunea fișierului va părea suspect de mică. Merită să știi asta înainte de a compara două rulări și de a trage concluzia că ceva s-a schimbat. Șterge un jurnal intenționat sau păstrează-l, dar știi care dintre cele două ai făcut. Dovada pe care ai îndepărtat-o deliberat este mai ușor de înțeles decât cea pe care ai pierdut-o din greșeală.

Niciuna dintre opțiuni nu creează directoare părinte lipsă și niciuna nu acordă acces prin permisiunile sistemului de fișiere sau printr-un sandbox al serviciului. O cale care pare corectă în configurație poate fi totuși nescriibilă de contul sub care rulează daemonul, iar atunci daemonul poate eșua înainte de a putea raporta ceva. Verifică dacă directorul există și cine îl deține înainte de a presupune că numele fișierului este problema.

Când un wrapper de serviciu captează rezultatul

În systemd, ieșirea standard și erorile merg în journal dacă o directivă explicită de fișier nu are prioritate, iar un wrapper al furnizorului le poate capta cu totul în altă parte.

De aceea același profil se comportă diferit dintr-un shell și dintr-o unit. Mediul unității, directorul ei de lucru și fluxurile standard diferă toate de shellul tău interactiv. O cale relativă se poate rezolva într-un context și nu ajunge nicăieri în celălalt. Citește definiția unității când cele două nu sunt de acord, nu profilul.

Compară cele două moduri de pornire în loc să concluzionezi că unul dintre ele este stricat. Citește linia de comandă a unității și mediul ei, apoi citește journalul pentru aceeași fereastră de timp. Dacă wrapperul redirecționează rezultatul în propriul fișier, acel fișier este acum jurnalul tău, iar directivele OpenVPN sunt irelevante pentru unde au ajuns mesajele.

Crește verbiozitatea doar după ce o poți citi

Creșterea verbiozității înainte de a găsi destinația produce doar mai mult text într-un loc la care nu te uiți.

Odată ce știi unde ajunge rezultatul, un nivel moderat arată profilul fiind parsat și conexiunea fiind încercată. Două sau trei sunt suficiente pentru o problemă de pornire. Nivelurile mai înalte își merită locul când eșecul este un detaliu de negociere, și fac și fișierul să crească repede.

Apoi citește eroarea reală. Un terminal tăcut nu dovedește nimic despre dacă tunelul a urcat, iar eșecul înregistrat în fișier este cel care merită reparat.