VPN-tsjinst falt by EXEC: fergelykje unit, binary en sudoers
Falen by stap EXEC betsjut dat systemd de binary net starte koe. Fergelykje it paad fan de unit, it ynstallearre paad en de sudoers-tastimming foardat jo wat wizigje.
Justplicht wurke de tunnel, en fan de moarn is de unit dea mei Failed at step EXEC spawning /usr/local/bin/vpnclient yn it journaal. Bewiisstikken, rûtes en it akkount komme nea yn dy sin. systemd hat ExecStart ta in paad oplost, it kernel frege it út te fieren, en it kernel wegere, meastentiids om’t der neat op dat paad is of om’t it bestân net útfierber is. Behannelje de flater as in bestân-en-argv-probleem oant de parsearre opdracht it tsjinoerstelde bewiist.
Wêrom EXEC falt foardat de autentikaasje begjint
systemd fiert ExecStart net fia in shell út. It docht in fork, bout in argumintfektor fan de rigel en ropt execve oan op it earste elemint. As dy oprop mislearret, berikt de tsjinst nea de eigen koade fan de VPN-klant, dus gjin profylbewurking of kontrôle fan bewiisstikken kin helpe.
De statuskoade skiedt dizze famylje fan gewoane crashes. In unit dy’t ôfslút mei status=203/EXEC hat nea in proses starten; in unit dy’t start en dan ôfslút mei status=1 is miskien mislearre by autentikaasje, DNS of routing. Lês de koade foar’t jo it kliïntloch lêze, want yn it earste gefal sil it kliïntloch leech wêze.
It paad yn it journaal is dat systemd brûkte, net needsaaklik dat jo bewurke hawwe. Drop-ins en generatorútfier kinne it bestân fan de leveransier oerskriuwe, en in ferâldere daemon-reload lit de âlde rigel yn it ûnthâld. Dêrom is de earste diagnoaze systemd freegje wat it tinkt dat de opdracht is, ynstee fan it bestân te iepenjen dat jo jo bewurke hawwe.
Trije plakken dêr’t it paad fan de binary skreaun stiet
In VPN-klant ynstallearre út in distribúsjepakket, in leveransierskript en in tarball fan in útjefte kin yn trije ferskillende foarheaksels telâne komme. De unit, de privilezje-regel en it ynstallaasjeprogramma hawwe elk ien fan dy foarheaksels fêstlein, en de flater ferskynt as twa fan de trije net oerienkomme.
| Record | Common value | How to read it |
|---|---|---|
| Unit or drop-in | /usr/local/bin/vpnclient | systemctl cat vpnclient.service |
| Installed binary | /usr/bin/vpnclient | command -v vpnclient, then ls -l the result |
| Sudoers grant | /opt/vpnclient/bin/vpnclient | sudo grep -r vpnclient /etc/sudoers.d/ |
In konkreet misferhâld sjocht der sa út: it leveransierskript ynstallearret nei /usr/local/bin, de tarball is útpakt ûnder /opt, en de unit neamt noch it âlde paad /usr/bin út in earder pakket. Fan dy bestannen bestiet mar ien, en it is selden dat yn ExecStart.
Beslis hokker paad kanonyk is foar’t jo ien fan de bestannen wizigje. As it distribúsjepakket de binary besit, is it pakketpaad kanonyk en de unit moat dat folgje. As it leveransierskript it besit, jildt deselde regel foar it foarheaksel fan de leveransier. In binary tusken foarheaksels kopiearje makket twa kopyen dy’t by de folgjende upgrade útinoar rinne.
As in oanheljende opdracht in bestânsnamme wurdt
In twadde flatermodus ferskûlet him efter deselde journaalrigel. Immen skriuwt dit yn de unit en ferwachtet dat de klant by it opstarten ferbynt:
ExecStart=/usr/bin/"vpnclient connect office"systemd splitst de wearde yn wurden, sadat it earste wurd /usr/bin/vpnclient connect office wurdt, wêrby’t de oanheljekens as groepearringssyntaksis fuorthelle wurde. Dan siket it kernel in bestân dêr’t romten yn de namme steane, en dat bestiet net. De flater is identyk oan in ûntbrekkende binary, ek al is de binary ynstallearre.
De stipe foarm is in echte útfierber bestân folge troch aparte arguminten, bygelyks ExecStart=/usr/bin/vpnclient connect office. As de wurkstream echt in piip of in ketting nedich hat, set it dan yn in skript en rop it skript oan, want ExecStart hat gjin &&, gjin pipen en gjin glob-útwreiding.
Reparearje de unit, net it bestânssysteem
De ferliedlike reparaasje is in symboalyske keppeling fan it ferwachte paad nei de echte binary. It wurket oant it pakket bywurke wurdt en de keppeling nei in fuorthelle bestân wiist, of oant in SELinux-label net mear by it doel past. Bewurkje de unit leaver fia in drop-in, sadat it bestân fan de leveransier ûnoantaast bliuwt en upgrades foarsisber bliuwe.
De privilezje-regel moat by itselde paad en deselde subopdrachten passe. In sudoers-ynskriuwing foar /usr/local/bin/vpnclient machtiget /usr/bin/vpnclient net, en in ynskriuwing dy’t elk argumint tastiet lit elk lokaal proses de tunnel werkonfigurearje of stopje. Jou de twa tiidwurden dy’t de unit nedich hat en hâld it ôfbrekken dêr bûten as it stopjen fan de tsjinst al de interface slút.
Hjir betellet de fergeliking him út: de unit, de pakketdatabase en sudoers soene allegear ien paad neame moatte. As se dat dogge, ferdwynt de EXEC-flater sûnder werstart en sûnder in kopy fan de binary op in tredde plak.
Bewiisje de parsearre opdracht foar de werstart
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-pagersystemctl show is de beslissende útfier, want it printsje de argv dy’t systemd eins parsearre hat, ynklusyf elke drop-in. systemd-analyze verify fangt in ûntbrekkend of net-útfierber paad foar’t jo werstarte, en de statusopdracht nei de werstart fertelt jo oft it proses no bestiet.
As de unit start en dan mislearret, hawwe jo de EXEC-famylje ferlitten en binne jo yn de eigen flaterôfhanneling fan de klant kommen. Sykje yn it journaal nei it berjocht fan de klant, net nei noch in execve-flater. Hâld de unit-diff en de sudoers-diff byinoar yn it feroaringsregister, sadat de folgjende upgrade it splitste paad net stilwei werombringt.