VPN-servo fiaskas ĉe EXEC: komparu unit, binaran dosieron kaj sudoers

Hieraŭ la tunelo funkciis, kaj hodiaŭ matene la unit estas morta kun Failed at step EXEC spawning /usr/local/bin/vpnclient en la ĵurnalo. Akreditaĵoj, itineroj kaj la konto neniam eniras tiun frazon. systemd solvis ExecStart al vojo, petis la kernon plenumi ĝin, kaj la kerno rifuzis, plej ofte ĉar nenio ekzistas ĉe tiu vojo aŭ ĉar la dosiero ne estas plenumebla. Traktu la difekton kiel problemon de dosiero kaj argv, ĝis la analizita komando pruvos la malon.

Kial EXEC fiaskas antaŭ ol komenciĝas la aŭtentikigo

systemd ne plenumas ExecStart per ŝelo. Ĝi faras forkon, konstruas argumentan vektoron el la linio kaj vokas execve sur la unuan elementon. Se tiu voko fiaskas, la servo neniam atingas la propran kodon de la VPN-kliento, do nek profilredaktado nek kontrolo de akreditaĵoj povas helpi.

La statusa kodo apartigas ĉi tiun familion de ordinaraj kraŝoj. Unit kiu finiĝas per status=203/EXEC neniam lanĉis procezon; unit kiu lanĉiĝas kaj poste finiĝas per status=1 eble fiaskis ĉe aŭtentikigo, DNS aŭ enrutigo. Legu la kodon antaŭ la klienta protokolo, ĉar en la unua kazo la klienta protokolo restos malplena.

La vojo en la ĵurnalo estas tiu, kiun systemd uzis, ne nepre tiu, kiun vi redaktis. Drop-in kaj generatora eligo povas anstataŭigi la dosieron de la vendisto, kaj kaduka daemon-reload lasas la malnovan linion en la memoro. Tial la unua diagnozo estas demandi systemd, kion ĝi konsideras la komando, anstataŭ malfermi la dosieron, kiun vi memoras ŝanĝinta.

Tri lokoj, kie la vojo de la binara dosiero estas skribita

VPN-kliento instalita el distribua pako, vendista skripto kaj eldona tarball povas finiĝi en tri malsamaj prefiksoj. La unit, la privilegia regulo kaj la instalilo ĉiu registris unu el tiuj prefiksoj, kaj la difekto aperas kiam du el la tri ne kongruas.

Konkreta malkongruo aspektas tiel: la vendista skripto instalas al /usr/local/bin, la tarball estis malpakita sub /opt, kaj la unit ankoraŭ nomas la malnovan vojon /usr/bin el antaŭa pako. Nur unu el tiuj dosieroj ekzistas, kaj malofte ĝi estas tiu en ExecStart.

Decidu, kiu vojo estas kanona, antaŭ ol ŝanĝi ajnan el la dosieroj. Se la distribua pako posedas la binaran dosieron, la paka vojo estas kanona kaj la unit devas sekvi ĝin. Se la vendista skripto posedas ĝin, la sama regulo validas por la vendista prefikso. Kopii binaran dosieron inter prefiksoj kreas du kopiojn, kiuj disiĝos ĉe la sekva ĝisdatigo.

Kiam citita komando fariĝas dosiernomo

Dua fiaskmaniero kaŝiĝas malantaŭ la sama ĵurnala linio. Iu skribas ĉi tion en la unit kaj atendas, ke la kliento konektiĝu dum la lanĉo:

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

systemd dividas la valoron en vortojn, do la unua vorto fariĝas /usr/bin/vpnclient connect office, kun la citiloj forigitaj kiel grupa sintakso. Poste la kerno serĉas dosieron, kies nomo enhavas spacojn, kaj tia ne ekzistas. La eraro identas al mankanta binara dosiero, kvankam la dosiero estas instalita.

La subtenata formo estas vera plenumebla dosiero sekvata de apartaj argumentoj, ekzemple ExecStart=/usr/bin/vpnclient connect office. Se la laborfluo vere bezonas tubon aŭ ĉenon, metu ĝin en skripton kaj voku la skripton, ĉar ExecStart havas neniun &&, neniujn tubojn kaj neniun glob-etendon.

Riparu la unit, ne la dosiersistemon

La tentiga riparo estas simbola ligilo de la atendata vojo al la vera binara dosiero. Ĝi funkcias ĝis la pako ĝisdatiĝos kaj la ligilo montros al forigita dosiero, aŭ ĝis SELinux-etikedo ne plu kongruos kun la celo. Prefere redaktu la unit per drop-in, por ke la dosiero de la vendisto restu netuŝita kaj la ĝisdatigoj restu antaŭvideblaj.

La privilegia regulo devas kongrui kun la sama vojo kaj la samaj subkomandoj. sudoers-ero por /usr/local/bin/vpnclient ne rajtigas /usr/bin/vpnclient, kaj ero, kiu permesas ĉiun argumenton, lasas ajnan lokan procezon rekonfiguri aŭ haltigi la tunelon. Donu la du verbojn, kiujn la unit bezonas, kaj tenu la malmuntadon ekster ĝi, se haltigo de la servo jam fermas la interfacon.

Ĉi tie la komparo pagiĝas: la unit, la paka datumbazo kaj sudoers ĉiuj devus nomi unu vojon. Kiam ili tion faras, la EXEC-eraro malaperas sen restartiĝo kaj sen kopio de la binara dosiero en tria loko.

Pruvu la analizitan komandon antaŭ restartiĝo

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 estas la decida eligo, ĉar ĝi presas la argv, kiun systemd efektive analizis, inkluzive de ajna drop-in. systemd-analyze verify kaptas mankantan aŭ neplenumeblan vojon antaŭ ol vi restartos, kaj la statusa komando post la restarto diras, ĉu la procezo nun ekzistas.

Se la unit lanĉiĝas kaj poste fiaskas, vi forlasis la EXEC-familion kaj eniris la propran erartraktadon de la kliento. Kontrolu la ĵurnalon por la mesaĝo de la kliento, ne por alia execve-fiasko. Tenu la unit-diff kaj la sudoers-diff kune en la ŝanĝprotokolo, por ke la sekva ĝisdatigo ne silente reenkonduku la dividitan vojon.