VPN-tenesta feilar ved EXEC: samanlikn unit, binærfil og sudoers

I går virka tunnelen, og i dag tidleg er unit-en død med Failed at step EXEC spawning /usr/local/bin/vpnclient i journalen. Påloggingsdata, ruter og kontoen dukkar aldri opp i den setninga. systemd løyste ExecStart til ein sti, bad kjernen køyre han, og kjernen nekta, oftast fordi det ikkje finst noko på den stien eller fordi fila ikkje er køyrbar. Handsama feilen som eit fil- og argv-problem til den analyserte kommandoen beviser det motsette.

Kvifor EXEC feilar før autentiseringa tek til

systemd køyrer ikkje ExecStart gjennom eit skal. Det gjer ein fork, byggjer ein argumentvektor frå linja og kallar execve på det første elementet. Viss det kallet feilar, når tenesta aldri inn i den eigen koden til VPN-klienten, så korkje profilredigering eller kontroll av påloggingsdata kan hjelpe.

Statuskoden skil denne familien frå vanlege krasj. Ein unit som avsluttar med status=203/EXEC har aldri starta ein prosess; ein unit som startar og deretter avsluttar med status=1 har kanskje feila på autentisering, DNS eller ruting. Les koden før du les klientloggen, for i det første tilfellet vil klientloggen vere tom.

Stien i journalen er den systemd brukte, ikkje nødvendigvis den du redigerte. Drop-ins og generatorutdata kan overstyre fila til leverandøren, og ein utdatert daemon-reload lèt den gamle linja bli i minnet. Difor er den første diagnosen å spørje systemd kva han meiner kommandoen er, i staden for å opne fila du hugsar du endra.

Tre stader der stien til binærfilen står skriven

Ein VPN-klient installert frå ein distribusjonspakke, eit leverandørskript og ein tarball frå ei utgjeving kan hamne i tre ulike prefiks. Unit-en, privilegieregelen og installatøren registrerte kvar sin av desse prefiksa, og feilen viser seg når to av dei tre ikkje stemmer.

Eit konkret avvik ser slik ut: leverandørskriptet installerer til /usr/local/bin, tarballen vart pakka ut under /opt, og unit-en nemner framleis den gamle /usr/bin-stien frå ein tidlegare pakke. Berre éi av desse filene finst, og det er sjeldan den i ExecStart.

Avgjer kva sti som er kanonisk før du endrar noka av filene. Viss distribusjonspakken eig binærfilen, er pakkestien kanonisk, og unit-en skal følgje han. Viss leverandørskriptet eig han, gjeld same regel for prefikset til leverandøren. Å kopiere ein binærfil mellom prefiks lagar to kopiar som glid frå kvarandre ved neste oppgradering.

Når ein kommando i hermeteikn blir eit filnamn

Ein andre feilmodus gøymer seg bak den same journallinja. Nokon skriv dette i unit-en og ventar at klienten koplar til under oppstart:

ExecStart=/usr/bin/"vpnclient connect office"

systemd deler verdien i ord, slik at det første ordet blir /usr/bin/vpnclient connect office, medan hermeteikna blir fjerna som grupperingssyntaks. Deretter leitar kjernen etter ei fil som har mellomrom i namnet, og det finst inga. Feilen er identisk med ein manglande binærfil, sjølv om binærfilen er installert.

Den støtta forma er ei ekte køyrbar fil etterfølgd av separate argument, til dømes ExecStart=/usr/bin/vpnclient connect office. Viss arbeidsflyten verkeleg treng ein pipeline eller ei kjede, legg han i eit skript og kall skriptet, fordi ExecStart har ingen &&, ingen røyr og inga glob-utviding.

Reparer unit-en, ikkje filsystemet

Den freistande reparasjonen er ei symbolsk lenkje frå den venta stien til den ekte binærfilen. Ho verkar til pakken blir oppdatert og lenkja peikar på ei fjerna fil, eller til ei SELinux-etikett ikkje lenger passar til målet. Føretrekk å redigere unit-en via ein drop-in, slik at fila til leverandøren blir urørt og oppgraderingar blir føreseielege.

Privilegieregelen må samsvare med den same stien og dei same underkommandoane. Ei sudoers-oppføring for /usr/local/bin/vpnclient autoriserer ikkje /usr/bin/vpnclient, og ei oppføring som tillèt alle argument, lèt kvar lokal prosess rekonfigurere eller stoppe tunnelen. Gi dei to verba unit-en treng, og hald nedrivinga utanfor viss stopping av tenesta alt lukkar grensesnittet.

Det er her samanlikninga løner seg: unit-en, pakkedatabasen og sudoers bør alle nemne éin sti. Når dei gjer det, forsvinn EXEC-feilen utan omstart og utan ein kopi av binærfilen på ein tredje stad.

Prov den analyserte kommandoen før omstart

sudo systemctl daemon-reload
sudo systemctl cat vpnclient.service
systemctl show -p ExecStart vpnclient.service
systemd-analyze verify /etc/systemd/system/vpnclient.service
sudo systemctl restart vpnclient.service
systemctl status vpnclient.service --no-pager

systemctl show er det avgjerande utdataet fordi det skriv ut argv-en systemd faktisk analyserte, inkludert kvar drop-in. systemd-analyze verify fangar opp ein manglande eller ikkje-køyrbar sti før du startar på nytt, og statuskommandoen etter omstarten fortel om prosessen no finst.

Viss unit-en startar og deretter feilar, har du forlate EXEC-familien og gått inn i eigen feilhandsaming hjå klienten. Sjå i journalen etter meldinga frå klienten, ikkje etter nok ein execve-feil. Hald unit-diffen og sudoers-diffen saman i endringsloggen, slik at neste oppgradering ikkje stille innfører den delte stien på nytt.