status=200/CHDIR: systemd startet aldri OpenVPN

Tjenesten feiler, loggene nevner en spawn og en mappe, og det første instinktet er å sjekke VPN-konfigurasjonen. Ingenting i den filen er lest ennå. systemd feilet mens den forberedte prosessen, før den kjørbare filen startet, så ingen parser, ingen sertifikat og ingen ekstern vert er konsultert. Å lese statuskoden som en uttalelse om systemd i stedet for om OpenVPN er det som gjør dette til en kort undersøkelse.

Les statuskoden før applikasjonen

Den numeriske koden etter tjenestenavnet navngir trinnet som feilet. En mappefeil rapporteres som CHDIR-status, mens en kjørbar fil som ikke kunne kjøres er en helt annen kode. De to ser like ut i en sammendragslinje og har ingenting til felles i årsakene sine.

Den forskjellen betyr noe fordi rettelsene er i forskjellige filer. En CHDIR-feil handler om en sti og tjenestens syn på den. En exec-feil handler om binæren, tolken dens eller en urelatert mount. Å endre VPN-remote, chifferlisten eller sertifikatstien kan ikke løse noen av dem.

Bekreft at feilen er ved oppstart og ikke etter en vellykket kjøring. Hvis tjenesten fungerte i går og nå feiler på samme trinn, er noe endret med mappen, dens tillatelser eller selve uniten, og den endringen er beviset du skal lete etter.

Spørr uniten hvor den vil være

Les den effektive uniten i stedet for filen du tror er installert, fordi drop-ins kan overstyre arbeidsmappen uten at du noen gang redigerer hoveduniten. Show-utdataene svarer direkte på spørsmålet:

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

For upstream-servermalen er arbeidsmappen serverkonfigurasjonsmappen, og instansnavnet velger profilen inni den. En instans som heter branch forventer derfor sin egen fil i samme mappe, og en profil plassert et annet sted oppfyller slett ikke kravet til arbeidsmappen.

Sammenlign det uniten ber om med det som finnes. En sti som pleide å finnes, en symbolsk lenke som nå peker et annet sted, eller et instansnavn som ikke lenger samsvarer med en mappe, er alle vanlige endringer som gir nøyaktig denne feilen.

Sjekk stien slik tjenesten ser den

Skallet ditt og tjenesten deler ikke samme visning av filsystemet. En konfigurert rotmappe eller root image endrer hva en absolutt sti betyr inne i uniten, og en sti som åpenbart finnes på verten kan mangle i det navnerommet. Les innstillingene til uniten før du stoler på en manuell test.

Tillatelser forsterker problemet. Tjenesten kjører som en bestemt bruker, og den brukeren må kunne gå gjennom hver overordnet mappe for å nå målet, ikke bare lese selve målet. En mappe som er lesbar for root og ikke gjennomgåelig for tjenestebrukeren gir en feil som ser ut som en manglende sti.

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

Herdingsinnstillinger er også en del av bildet. En unit som skjuler hjemmemapper eller gjør en del av filsystemet skrivebeskyttet, gjør nøyaktig det den er konfigurert til, og arbeidsmappen må ligge et sted der sandkassen fortsatt eksponerer den.

Fiks eieren, forvent så en annen feil

Korriger oppsettet eller uniten gjennom den som eier den konfigurasjonen. Å flytte en profil inn i den forventede mappen er en legitim rettelse når oppsettet er feil, men det forklarer ikke en mappe som ikke kan betres, så ikke behandle det som det generelle svaret.

Motstå snarveien med å utvide tillatelsene på konfigurasjonstreet eller fjerne sandkassen. Begge får symptomet til å forsvinne samtidig som de fjerner beskyttelsen som ble lagt der med vilje, og neste feil blir vanskeligere å tolke.

Start instansen på nytt og les neste hendelse i stedet for å anta suksess. Den sannsynlige neste feilen er at OpenVPN ikke kan åpne konfigurasjonsfilen sin, noe som er fremgang: arbeidsmappen ble betret og parseren kjører nå. Følg unitens faktiske filkartlegging derfra i stedet for å gå tilbake til nettverksfeilsøking.

systemd-referansen for kjøring definerer hvordan arbeidsmappen tolkes sammen med rotmapper og sandkassing. Mønsteret å huske er enkelt: hver statuskode navngir et annet trinn, og bare applikasjonens egne feil beskriver applikasjonen.