Starte ein teneste på nytt ved OpenVPN up: krokar slår tun0.device

Å kople ei avhengig teneste til tun0.device ser ut som å abonnere på tunnelen, og det er det ikkje. Ei einingseining speglar at grensesnittet finst, noko som kan halde fram med å vere sant gjennom ei mislukka tilkopling og gjenoppkoplinga som følgjer. Tenesta handlar då på feil tidspunkt, eller aldri, avhengig av om grensesnittet forsvann i mellomtida. Kroken som skildrar hendinga du faktisk bryr deg om, er den OpenVPN kallar, ikkje den systemd leier ut.

Avgjer kva vilkår tenesta treng før du vel utløysaren, fordi dei tre kandidatane ikkje er utskiftbare.

Kva einingseininga faktisk følgjer

systemd lagar ei einingseining frå synet til kjernen på eit nettverksgrensesnitt, så tun0.device vert aktiv når grensesnittet dukkar opp og inaktiv når det vert fjerna. Med persist-tun held ein mjuk omstart grensesnittet på plass, så eininga flappar aldri og ingenting bunde til ho vert utløyst. Sjølv utan persistens seier eininga ingenting om ruter, DNS eller om den fjerne enden svarar.

Det gjer ho til ein dårleg stand-in for 'VPN-et er klart'. Ein lyttar som berre treng den lokale adressa, kan nøye seg med at grensesnittet finst, medan ei teneste som kallar ein applikasjon på det fjerne nettverket treng ruter og tilgjenge, som einingseininga ikkje kan uttrykke.

up, route-up og up-restart tyder ulike ting

up køyrer etter at TUN/TAP-eininga er opna og grensesnittet er konfigurert, som er rett tidspunkt for ein lyttar som bind den tildelte adressa. route-up køyrer etter at ruter er installerte, underlagd kvar konfigurert ruteforsinking, og passar for arbeid som treng ruterfasen fullført. Ingen av dei provar at den fjerne applikasjonen svarar. Å velje mellom dei er eit spørsmål om kva tenesta treng, ikkje om kva krok som høyrest meir ferdig ut.

Med persist-tun brukar omstartar eininga på nytt, så up køyrer ikkje igjen med mindre up-restart er sett. Det valet aktiverer up-skriptet for den dokumenterte omstartslivssyklusen, og miljøet er redusert samanlikna med ein første start. Eit skript som føreset det fulle miljøet, verkar ved den første tilkoplinga og feilar ved den neste.

Send handlinga utan å vente på ho

Ein krok som kallar systemctl restart synkront, kan gå i vranglås mot ei eining der rekkjefølgja ventar på tunnelen. systemctl --no-block try-restart vpn-dependent.service set jobben i kø og returnerer, noko som hindrar kroken i å blokkere tilkoplinga han reagerte på. try-restart verkar berre på ei køyrande eining, medan restart òg startar ei inaktiv; vel medvite, ikkje av vane.

Køing er ikkje verifisering. Kroken returnerer suksess så snart jobben er godteken, så kontrollen må skje i journalen til måleininga eller i den faktiske lyttartilstanden hennar.

Omstartspolitikk bur i eininga, ikkje i kroken

Ei oneshot-eining med RemainAfterExit=yes held fram som aktiv etter at kommandoen er ferdig, og ein ny startførespurnad gjer ingenting fordi systemd reknar ho som alt starta. Det er ein eigenskap ein designar rundt, ikkje ein feil ein omgår med gjentekne startkall. Viss handlinga må køyre per tilkopling, treng eininga ei form som tillèt det.

After= ordnar einingar, og BindsTo= bind levealdrar, men ingen av dei tyder 'start dette på nytt kvar gong VPN-et koplar til igjen'. Ei eining bunde til tunnelen stoggar når tunnelen stoggar; ho startar ikkje seg sjølv på nytt når tunnelen kjem tilbake, med mindre noko startar ho igjen.

Test tre gjenoppkoplingar, ikkje éin

Kald oppstart, ein full klientomstart og ei mjuk gjenoppkopling øver kvar sin veg. Den mjuke gjenoppkoplinga er den som avdekkjer ein manglande up-restart, eit redusert miljø eller ei einingseining som aldri vart inaktiv. Køyr alle tre og stadfest båe retningane: tenesta handlar når tunnelen kjem opp, og ho startar ikkje på nytt ved urelaterte lenkeendringar som Wi-Fi-roaming.

Hald ein uavhengig gjenopprettingsveg når den avhengige tenesta ber din eigen administrative tilgang. Ein krok som startar det du er tilkopla gjennom på nytt, er ei endring som kan låse deg ute.