status=200/CHDIR: systemd nikad nije pokrenuo OpenVPN

Servis pada, u logovima se spominju spawn i direktorij, a prvi instinkt je provjeriti VPN konfiguraciju. Ništa u toj datoteci još nije pročitano. systemd je pao dok je pripremao proces, prije nego što se izvršna datoteka pokrenula, pa nijedan parser, nijedan certifikat i nijedan udaljeni host nisu bili konzultirani. Čitanje statusnog koda kao izjave o systemd-u, a ne o OpenVPN-u, pretvara ovo u kratku istragu.

Pročitajte statusni kod prije aplikacije

Numerički kod nakon naziva servisa imenuje fazu koja je pala. Greška direktorija prijavljuje se kao CHDIR status, dok je izvršna datoteka koja se nije mogla pokrenuti potpuno drugi kod. Ta dva u sažetku izgledaju slično i nemaju ništa zajedničko u uzrocima.

Ta razlika je važna jer su popravci u različitim datotekama. CHDIR greška se odnosi na putanju i na to kako je servis vidi. Exec greška se odnosi na binarnu datoteku, njezin interpreter ili nepovezani mount. Promjena VPN udaljene točke, popisa šifri ili putanje certifikata ne može riješiti nijednu od njih.

Potvrdite da je greška na startu, a ne nakon uspješnog rada. Ako je servis jučer radio, a sada pada u istoj fazi, nešto se promijenilo u vezi s direktorijem, njegovim dozvolama ili samim unitom, i ta promjena je dokaz koji treba tražiti.

Pitajte unit gdje želi biti

Čitajte efektivni unit, a ne datoteku za koju mislite da je instalirana, jer drop-in datoteke mogu nadjačati radni direktorij, a da nikada ne uredite glavni unit. Show izlaz izravno odgovara na pitanje:

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

Za predložak upstream poslužitelja, radni direktorij je direktorij konfiguracije poslužitelja, a naziv instance bira profil unutar njega. Instanca zvana branch zato očekuje svoju datoteku u tom istom direktoriju, a profil postavljen negdje drugdje uopće ne zadovoljava zahtjev radnog direktorija.

Usporedite što unit traži s onim što postoji. Putanja koja je nekada postojala, simbolička poveznica koja sada pokazuje negdje drugdje ili naziv instance koji više ne odgovara direktoriju sve su obične promjene koje proizvode upravo ovu grešku.

Provjerite putanju kako je vidi servis

Vaš shell i servis ne dijele isti pogled na datotečni sustav. Konfigurirani korijenski direktorij ili root image mijenja što apsolutna putanja znači unutar unita, a putanja koja je očito prisutna na hostu može biti odsutna u tom namespaceu. Pročitajte postavke unita prije nego povjerujete ručnom testu.

Dozvole pogoršavaju problem. Servis radi kao određeni korisnik, a taj korisnik mora moći proći kroz svaki nadređeni direktorij da bi stigao do cilja, a ne samo čitati sam cilj. Direktorij čitljiv za root, a neprohodan za korisnika servisa, proizvodi grešku koja izgleda kao da putanja nedostaje.

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

Postavke očvršćivanja također su dio ove slike. Unit koji skriva kućne direktorije ili dio datotečnog sustava čini samo za čitanje radi upravo ono za što je konfiguriran, a radni direktorij mora živjeti negdje gdje ga sandbox još izlaže.

Popravite vlasnika, pa očekujte drugu grešku

Ispravite raspored ili unit preko onoga koji posjeduje tu konfiguraciju. Premještanje profila u očekivani direktorij legitiman je popravak kada je raspored pogrešan, ali ne objašnjava direktorij u koji se ne može ući, pa to ne tretirajte kao opći odgovor.

Oduprite se prečacu proširenja dozvola na stablu konfiguracije ili uklanjanja sandboxa. Oboje uklanja simptom, a istovremeno uklanja zaštite koje su tamo namjerno stavljene, i sljedeću će grešku biti teže protumačiti.

Ponovno pokrenite instancu i pročitajte sljedeći događaj umjesto da pretpostavite uspjeh. Vjerojatna sljedeća greška je da OpenVPN ne može otvoriti svoju konfiguracijsku datoteku, što je napredak: u radni se direktorij ušlo i parser sada radi. Odande slijedite stvarno mapiranje datoteka unita umjesto da se vraćate na mrežno rješavanje problema.

systemd referenca za izvršavanje definira kako se radni direktorij tumači zajedno s korijenskim direktorijima i sandboxingom. Obrazac koji treba zapamtiti jednostavan je: svaki statusni kod imenuje drugu fazu, i samo vlastite greške aplikacije opisuju aplikaciju.