Másoljon egy működő parancssort az ExecStartba, töltse újra, és az egység meghibásodik vagy csendben kilép, mert az argumentumokat fájlnévként kezeli. A systemd-ben semmi nem tört el. Az ExecStart argumentumlista, nem shell, ezért a csövek, az átirányítás és a feltételek elveszítik értelmüket abban a pillanatban, amikor elhagyják a terminált. Döntse el, hová tartozik a shell, majd írjon egységet, amely pontosan megmondja, mit kell végrehajtani.

Miért nem tesz semmit az ExecStart csöve

Amikor egy parancsot beírunk a terminálba, a shell először elemzi azt. Csövet épít, fájlokat nyit meg az átirányításhoz, és kiterjeszti a változókat, mielőtt bármely program elindulna. A systemd ebből semmit nem tesz: saját szabályai szerint bontja fel az ExecStartot, és az így kapott programot futtatja ezekkel az argumentumokkal. Ezért > szó szerinti argumentumként érkezik, és a | átadódik a programnak ahelyett, hogy két folyamatot kötne össze. Az egység nem viselkedik rosszul; a szintaxis mást jelentett.

Ez szándékos, nem hanyagság, mert az argumentumok kiszámítható kezelése teszi auditálhatóvá az egységeket. Csak azokat lepi meg, akik feltételezik, hogy van shell.

Írjon egységet, amely pontosan megmondja, mi fut

Kezdje egy kis egységgel, amelynek célja látszik a naplóban, hogy az elemzési problémák elkülönüljenek az alagútproblémáktól. Ez csak egy bináris verzióját jelenti.

[Unit]
Description=Report the installed OpenVPN version

[Service]
Type=oneshot
ExecStart=/usr/sbin/openvpn --version
StandardOutput=journal
StandardError=journal

Az útvonal helyőrző, ezért cserélje ki a ténylegesen telepített binárisra. Type=oneshot olyan parancshoz illik, amely a végéig fut, a naplóbeállítások pedig oda teszik a kimenetét, ahol terminál nélkül is olvashatja. Szándékosan nincs telepítési szakasz, ezért az egységet kézzel hívják meg, nem pedig indításkor engedélyezik. Indítás előtt ellenőrizze a fájlt, mert egy direktívanév elírása másképp vall kudarcot, mint egy elírás az útvonalban.

systemd-analyze verify /etc/systemd/system/openvpn-version.service
systemctl start openvpn-version.service

Tartsa a shell-logikát szkriptben

Amikor egy segédnek valóban feltételes logikára van szüksége, tegye azt a logikát szkriptbe, és hívja meg kifejezetten. A szkriptnek értelmezősorra, végrehajtási engedélyre és olyan kilépési kódokra van szüksége, amelyeket a szolgáltatás jelenteni tud. A /bin/sh -c futtatása idézőjeles paranccsal működik, de elrejti az idézőjelezési szabályokat egy egységen belül, és megnehezíti az áttekintést. Egy nevesített szkript kézzel tesztelhető, és később az egység szerkesztése nélkül lecserélhető. Ne hagyatkozzon az interaktív felhasználó shell-profiljára, mert a szolgáltatás a saját környezetével indul.

Állítsa be a WorkingDirectory értéket, amikor a relatív útvonalak számítanak, és a környezetet az egység támogatott direktíváin keresztül adja át, ne pedig terminálban exportálja. A titkok védett fájlokba vagy hitelesítő adatokba tartoznak, nem olyan argumentumlistákba, amelyeket a napló rögzíthet.

Ellenőrizze azt az egységet, amely valóban létezik

A drop-in fájlok megváltoztatják a viselkedést anélkül, hogy hozzányúlnának ahhoz a fájlhoz, amelyet szerkesztettnek emlékszik. Olvassa el, mit töltött be a kezelő, és mit jelentett az utolsó futás.

systemctl cat vpn-helper.service
journalctl -u vpn-helper.service -n 20 --no-pager

Az egység kiírása betöltési sorrendben tartalmazza a drop-in fájlokat, és általában innen származik a váratlan ExecStart. Minden változtatás után töltse újra a kezelőt, és erősítse meg, hogy az új definíció az, amit a systemctl cat kiír. A napló megmutatja a pontos parancssort és a kilépési állapotot, ami elválasztja az argumentumproblémát a hiányzó bináristól vagy az engedélyhibától. Utána döntse el, hogy a segéd a meglévő VPN-életciklushoz tartozik-e, vagy kézi diagnosztikának kell maradnia, mert egy második háttér-alagútfolyamat versengő tulajdonost hoz létre.

Az az egység, amely kérésre a helyes kimenetet írja ki, jó első mérföldkő. Még nem alagút, és nem is szabad annak látszania.

Kapcsolódó cikkek