status=200/CHDIR: systemd startade aldrig OpenVPN

Tjänsten misslyckas, loggarna nämner en spawn och en katalog, och det första instinktet är att kontrollera VPN-konfigurationen. Ingenting i den filen har lästs ännu. systemd misslyckades medan den förberedde processen, innan den körbara filen startade, så ingen parser, inget certifikat och ingen fjärrvärd har konsulterats. Att läsa statuskoden som ett uttalande om systemd i stället för om OpenVPN är det som gör detta till en kort undersökning.

Läs statuskoden före applikationen

Den numeriska koden efter tjänstenamnet namnger steget som misslyckades. Ett katalogfel rapporteras som CHDIR-status, medan en körbar fil som inte kunde köras är en helt annan kod. De två ser lika ut i en sammanfattningsrad och har ingenting gemensamt i sina orsaker.

Den skillnaden spelar roll eftersom åtgärderna finns i olika filer. Ett CHDIR-fel handlar om en sökväg och hur tjänsten ser den. Ett exec-fel handlar om binären, dess tolk eller en orelaterad montering. Att ändra VPN-remote, chifferlistan eller certifikatsökvägen kan inte lösa någon av dem.

Bekräfta att felet är vid start och inte efter en lyckad körning. Om tjänsten fungerade i går och nu misslyckas i samma steg har något ändrats med katalogen, dess behörigheter eller själva uniten, och den ändringen är beviset du ska leta efter.

Fråga uniten var den vill vara

Läs den effektiva uniten i stället för filen du tror är installerad, eftersom drop-ins kan åsidosätta arbetskatalogen utan att du någonsin redigerar huvuduniten. Show-utdata svarar direkt på frågan:

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

För upstream-servermallen är arbetskatalogen serverkonfigurationskatalogen och instansnamnet väljer profilen inuti den. En instans som heter branch förväntar sig därför sin egen fil i samma katalog, och en profil placerad någon annanstans uppfyller inte alls kravet på arbetskatalog.

Jämför vad uniten begär med vad som finns. En sökväg som brukade finnas, en symbolisk länk som nu pekar någon annanstans eller ett instansnamn som inte längre matchar en katalog är alla vanliga ändringar som ger exakt detta fel.

Kontrollera sökvägen så som tjänsten ser den

Ditt skal och tjänsten delar inte samma vy av filsystemet. En konfigurerad rotkatalog eller root image ändrar vad en absolut sökväg betyder inne i uniten, och en sökväg som uppenbart finns på värden kan saknas i den namnrymden. Läs unitens inställningar innan du litar på ett manuellt test.

Behörigheter förvärrar problemet. Tjänsten körs som en specifik användare, och den användaren måste kunna gå igenom varje överordnad katalog för att nå målet, inte bara läsa själva målet. En katalog som är läsbar för root och inte genomgångbar för tjänsteanvändaren ger ett fel som ser ut som en saknad sökväg.

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

Härdningsinställningar är också en del av bilden. En unit som döljer hemkataloger eller gör en del av filsystemet skrivskyddat gör exakt det den är konfigurerad för, och arbetskatalogen måste ligga någonstans där sandlådan fortfarande exponerar den.

Åtgärda ägaren och förvänta dig sedan ett annat fel

Korrigera layouten eller uniten via den som äger den konfigurationen. Att flytta en profil till den förväntade katalogen är en legitim åtgärd när layouten är fel, men det förklarar inte en katalog som inte går att komma in i, så behandla det inte som det generella svaret.

Motstå genvägen att utöka behörigheterna på konfigurationsträdet eller ta bort sandlådan. Båda får symtomet att försvinna samtidigt som de tar bort skydden som placerades där med avsikt, och nästa fel blir svårare att tolka.

Starta om instansen och läs nästa händelse i stället för att anta framgång. Nästa troliga fel är att OpenVPN inte kan öppna sin konfigurationsfil, vilket är framsteg: arbetskatalogen beträddes och parsern kör nu. Följ unitens faktiska filmappning därifrån i stället för att återgå till nätverksfelsökning.

systemd-referensen för körning definierar hur arbetskatalogen tolkas tillsammans med rotkataloger och sandlåda. Mönstret att komma ihåg är enkelt: varje statuskod namnger ett annat steg, och bara applikationens egna fel beskriver applikationen.