status=200/CHDIR: systemd heeft OpenVPN nooit gestart

De dienst faalt, de logs noemen een spawn en een map, en de eerste reflex is de VPN-configuratie controleren. In dat bestand is nog niets gelezen. systemd faalde tijdens het voorbereiden van het proces, voordat het uitvoerbare bestand startte, dus er is geen parser, geen certificaat en geen externe host geraadpleegd. De statuscode lezen als een uitspraak over systemd in plaats van over OpenVPN is wat dit tot een kort onderzoek maakt.

Lees de statuscode vóór de applicatie

De numerieke code na de dienstnaam benoemt de fase die faalde. Een mapfout wordt gemeld als CHDIR-status, terwijl een uitvoerbaar bestand dat niet kon worden gestart een volledig andere code is. De twee lijken op elkaar in een samenvattingsregel en hebben niets gemeen in hun oorzaken.

Dat onderscheid is belangrijk omdat de oplossingen in verschillende bestanden zitten. Een CHDIR-fout gaat over een pad en hoe de dienst dat ziet. Een exec-fout gaat over het binaire bestand, zijn interpreter of een niet-gerelateerde mount. Het wijzigen van de VPN-remote, de cijferlijst of het certificaatpad lost geen van beide op.

Bevestig dat de fout bij de start optreedt en niet na een geslaagde run. Als de dienst gisteren werkte en nu in dezelfde fase faalt, is er iets veranderd aan de map, de machtigingen of de unit zelf, en die verandering is het bewijs waarnaar je moet zoeken.

Vraag de unit waar hij wil zijn

Lees de effectieve unit in plaats van het bestand waarvan je denkt dat het geïnstalleerd is, omdat drop-ins de werkmap kunnen overschrijven zonder dat je ooit de hoofdunit bewerkt. De show-uitvoer beantwoordt de vraag direct:

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

Voor de upstream-servertemplate is de werkmap de serverconfiguratiemap en de instantienaam selecteert het profiel daarin. Een instantie met de naam branch verwacht dus zijn eigen bestand in dezelfde map, en een profiel dat elders is geplaatst voldoet helemaal niet aan de werkmap-eis.

Vergelijk wat de unit vraagt met wat bestaat. Een pad dat vroeger bestond, een symbolische link die nu ergens anders heen wijst, of een instantienaam die niet meer bij een map past, zijn allemaal gewone wijzigingen die precies deze fout opleveren.

Controleer het pad zoals de dienst het ziet

Je shell en de dienst delen niet dezelfde kijk op het bestandssysteem. Een geconfigureerde hoofdmap of root image verandert wat een absoluut pad binnen de unit betekent, en een pad dat duidelijk op de host aanwezig is, kan in die namespace ontbreken. Lees de instellingen van de unit voordat je een handmatige test vertrouwt.

Machtigingen verergeren het probleem. De dienst draait als een specifieke gebruiker, en die gebruiker moet elke bovenliggende map kunnen doorkruisen om het doel te bereiken, niet alleen het doel zelf lezen. Een map die leesbaar is voor root en niet doorkruisbaar voor de dienstgebruiker, levert een fout op die op een ontbrekend pad lijkt.

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

Hardeningsinstellingen horen ook bij dit beeld. Een unit die thuismappen verbergt of een deel van het bestandssysteem alleen-lezen maakt, doet precies waarvoor hij is geconfigureerd, en de werkmap moet ergens staan waar de sandbox hem nog blootstelt.

Repareer de eigenaar en verwacht dan een andere fout

Corrigeer de indeling of de unit via degene die die configuratie bezit. Een profiel naar de verwachte map verplaatsen is een legitieme oplossing als de indeling verkeerd is, maar het verklaart geen map waar je niet in kunt, dus behandel het niet als het algemene antwoord.

Weersta de sluiproute om machtigingen op de configuratieboom te verruimen of de sandbox te verwijderen. Beide laten het symptoom verdwijnen terwijl ze de beschermingen weghalen die daar bewust zijn neergezet, en de volgende storing wordt moeilijker te interpreteren.

Herstart de instantie en lees de volgende gebeurtenis in plaats van succes aan te nemen. De waarschijnlijke volgende fout is dat OpenVPN zijn configuratiebestand niet kan openen, wat vooruitgang is: de werkmap is betreden en de parser draait nu. Volg vanaf daar de werkelijke bestandsmapping van de unit in plaats van terug te keren naar netwerkproblemen.

De systemd-uitvoeringsreferentie definieert hoe de werkmap wordt geïnterpreteerd samen met hoofdmap en sandboxing. Het patroon om te onthouden is eenvoudig: elke statuscode benoemt een andere fase, en alleen de eigen fouten van de applicatie beschrijven de applicatie.