Fișier PID prezent, niciun tunel: a rulat OpenVPN vreodată?

Când lansatorul refuză să pornească OpenVPN pentru că există deja un fișier PID, lectura firească este că undeva rulează un tunel. Acea lectura este greșită suficient de des încât să merite verificată înainte de a șterge ceva. Un fișier într-un director de execuție este contabilitate, iar contabilitatea supraviețuiește căderilor, repornirilor și opririlor întrerupte care nu au lăsat niciun proces. Două întrebări decid cazul: există un proces viu și acel proces aparține acestei instanțe.

Începeți cu serviciul, nu cu fișierul

Refuzul vine de obicei de la un lansator și nu de la OpenVPN însuși. Citește o cale, găsește ceva acolo și se oprește înainte de a analiza o configurație. Prima întrebare este deci despre contractul lansatorului, nu despre tunel.

Citiți unitatea sau scriptul care a tipărit mesajul și notați trei lucruri: calea pe care o verifică, tipul de serviciu pe care îl declară și dacă este responsabil pentru scrierea fișierului. O unitate modernă poate folosi supraveghere simplă sau notify și nu atinge niciodată un fișier PID, în timp ce un script init mai vechi poate crea unul singur. Copierea unei verificări dintr-un model în altul produce exact acest tip de refuz. Aflați ce model este folosit înainte de a interpreta orice.

Abia atunci întrebarea devine dacă o instanță rulează într-adevăr.

Verificați dacă acel identificator aparține instanței dumneavoastră

Un număr într-un fișier dovedește că s-a scris un număr. Nu dovedește că există acum un proces cu acel identificator și cu siguranță nu dovedește că procesul este al dumneavoastră, pentru că identificatorii sunt reutilizați după o repornire.

Comparați ora de pornire a procesului cu marcajul de timp al fișierului, executabilul cu comanda unității și apartenența la serviciu cu numele unității. O nepotrivire în oricare dintre cele trei înseamnă că priviți contabilitate, nu un tunel.

Pe un host care rulează containere sau mai multe spații de nume, un identificator poate fi semnificativ într-o vizualizare și absent în alta. Faptul că nu vedeți un proces nu este nici el o dovadă că nu există, dacă contul dumneavoastră nu îl poate inspecta. Verificați din contextul pe care îl folosește lansatorul înainte de a trage concluzii.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Ce a promis lansatorul că va face cu fișierul

PIDFile= îi spune managerului de servicii de unde să citească identificatorul procesului principal. Managerul nu scrie acel fișier, dar elimină unul care supraviețuiește după oprire, și exact de aceea o ieșire întreruptă poate lăsa un fișier.

Această împărțire a responsabilităților explică două simptome pe care oamenii le raportează ca erori. Un fișier care nu apare niciodată înseamnă că demonul sau scriptul lui nu l-a putut scrie, nu că supravegherea este configurată greșit. Un fișier care supraviețuiește unei opriri înseamnă că traseul de oprire nu s-a încheiat niciodată.

Explică și de ce îndrumările actuale sugerează evitarea convenției când supravegherea poate urmări direct procesul principal. Acele îndrumări nu sunt o permisiune de a schimba tipul unei unități împachetate, pentru că comportamentul demonului în prim-plan, la bifurcare sau la notificare trebuie să corespundă cu ceea ce declară unitatea. Schimbați tipul fără a schimba demonul și obțineți o unitate care raportează o eroare în timp ce tunelul rulează, sau invers. Potriviți perechea sau lăsați ambele. Referința serviciului systemd descrie această împărțire a proprietății.

Oprire curată versus ieșire întreruptă

O oprire curată cere demonului să iasă, îl așteaptă și îi permite managerului să își pună în ordine propria contabilitate. O ieșire întreruptă, un proces omorât sau o repornire în mijlocul opririi sar peste părți din acea secvență, iar fișierul este ceea ce rămâne. Găsirea unuia după o cădere vă spune că oprirea nu s-a terminat, nu că ceva ascultă.

Comparați marcajul de timp al fișierului cu ultima pornire și cu ultima oprire a unității.

Apoi verificați dovezile vii direct. Un socket legat la portul VPN și o interfață de tunel cu adresă sunt dovada că ceva rulează, într-un mod în care un fișier text într-un director de execuție nu este niciodată. Dacă lipsesc ambele, nu rulează nimic, orice ar afirma fișierul.

Opriți-vă din a șterge fișierul din obișnuință

Ștergerea lui este un pas de recuperare legitim după ce ați stabilit că nicio instanță nu îl deține și că lansatorul documentează acest comportament.

Ca obișnuință permanentă înainte de pornire, anulează verificarea pe care o ocoliți. Dacă fișierele învechite revin după fiecare oprire curată, scriitorul și ciclul de viață al opririi nu sunt de acord cine deține calea, iar acea neînțelegere este eroarea care merită corectată.

Păstrați o cale independentă către host, porniți o instanță prin managerul ei normal și citiți primul rezultat. Următoarea persoană primește o unitate care fie funcționează, fie se explică.