status=200/CHDIR: systemd nu a pornit niciodată OpenVPN

Serviciul eșuează, jurnalele menționează un spawn și un director, iar primul instinct este să verifici configurația VPN. Din acel fișier nu s-a citit încă nimic. systemd a eșuat în timp ce pregătea procesul, înainte ca executabilul să ruleze, deci nu a fost consultat niciun parser, niciun certificat și niciun host la distanță. Citirea codului de stare ca afirmație despre systemd și nu despre OpenVPN este ceea ce transformă asta într-o investigație scurtă.

Citește codul de stare înainte de aplicație

Codul numeric de după numele serviciului numește etapa care a eșuat. O eroare de director este raportată ca stare CHDIR, în timp ce un executabil care nu a putut fi rulat este un cod complet diferit. Cele două arată similar într-o linie de sumar și nu au nimic în comun în cauzele lor.

Această distincție contează pentru că remediile sunt în fișiere diferite. O eroare CHDIR ține de o cale și de modul în care serviciul o vede. O eroare exec ține de binar, de interpretorul lui sau de un mount nelegat. Schimbarea remote-ului VPN, a listei de cifruri sau a căii certificatului nu poate rezolva niciuna dintre ele.

Confirmă că eroarea apare la pornire și nu după o rulare reușită. Dacă serviciul a funcționat ieri și acum eșuează în aceeași etapă, ceva s-a schimbat la director, la permisiunile lui sau la unit-ul însuși, iar acea schimbare este dovada pe care trebuie să o cauți.

Întreabă unit-ul unde vrea să fie

Citește unit-ul efectiv și nu fișierul pe care crezi că l-ai instalat, pentru că drop-in-urile pot suprascrie directorul de lucru fără ca tu să fi editat vreodată unit-ul principal. Ieșirea show răspunde direct la întrebare:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Pentru șablonul de server upstream, directorul de lucru este directorul de configurație al serverului, iar numele instanței selectează profilul din interior. O instanță numită branch așteaptă, așadar, propriul fișier în același director, iar un profil plasat în altă parte nu satisface deloc cerința directorului de lucru.

Compară ce cere unit-ul cu ce există. O cale care exista cândva, o legătură simbolică ce indică acum altundeva sau un nume de instanță care nu mai corespunde unui director sunt toate schimbări obișnuite care produc exact această eroare.

Verifică calea așa cum o vede serviciul

Shell-ul tău și serviciul nu împărtășesc aceeași vedere a sistemului de fișiere. Un director rădăcină sau o imagine rădăcină configurate schimbă ce înseamnă o cale absolută în interiorul unit-ului, iar o cale evident prezentă pe host poate lipsi în acel namespace. Citește setările unit-ului înainte de a te încrede într-un test manual.

Permisiunile agravează problema. Serviciul rulează ca un utilizator specific, iar acel utilizator trebuie să poată traversa fiecare director părinte pentru a ajunge la țintă, nu doar să citească ținta în sine. Un director lizibil de root și netraversabil de utilizatorul serviciului produce o eroare care arată ca o cale lipsă.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Setările de întărire fac și ele parte din acest tablou. Un unit care ascunde directoarele home sau face o parte a sistemului de fișiere doar-citire face exact ceea ce a fost configurat să facă, iar directorul de lucru trebuie să se afle undeva unde sandbox-ul încă îl expune.

Corectează proprietarul, apoi așteaptă o altă eroare

Corectează aspectul sau unit-ul prin cel care deține acea configurație. Mutarea unui profil în directorul așteptat este o remediere legitimă când aspectul este greșit, dar nu explică un director în care nu se poate intra, așa că nu o trata ca răspunsul general.

Rezistă tentației de a lărgi permisiunile pe arborele de configurație sau de a elimina sandbox-ul. Ambele fac simptomul să dispară în timp ce elimină protecțiile puse acolo intenționat, iar următoarea eroare va fi mai greu de interpretat.

Repornește instanța și citește următorul eveniment în loc să presupui succesul. Următoarea eroare probabilă este că OpenVPN nu poate deschide fișierul său de configurație, ceea ce este un progres: s-a intrat în directorul de lucru și parserul rulează acum. Urmează de acolo maparea reală a fișierelor unit-ului în loc să te întorci la depanarea rețelei.

Referința de execuție systemd definește modul în care directorul de lucru este interpretat împreună cu directoarele rădăcină și izolarea. Tiparul de reținut este simplu: fiecare cod de stare numește o etapă diferită, iar doar erorile aplicației înseși descriu aplicația.