Hvers vegna VPN-eining ræsist fyrir netið og deyr svo

Ræsið vélina, skráið ykkur inn og komist að því að göngin komu upp og dóu nokkrum sekúndum síðar. Prófíllinn var í lagi, skírteinið var í lagi, og eina eftirleikinn er dagbókin frá þeirri ræsingu. Það sem venjulega gerðist er kapphlaup: einingin ræstist áður en vélin hafði tölu, og röðin sem hún lýsti yfir þýddi ekki það sem hún lítur út fyrir. Allt hér að neðan snýst um að sanna þetta kapphlaup út frá sönnunargögnum og loka því almennilega.

Markmiðið er fundarstaður, ekki stjórnandi

network-online.target hefur ekki hugmynd um hvað net er. Það er samhæfingarpunktur sem safnar þeirri þjónustu sem á að tefja ræsingu þar til tengingin er nothæf, og það framselur skilgreininguna til þess netstjóra sem á vélina. Á flestum skjáborðum og netþjónum þýðir það biðþjónustu sem NetworkManager eða systemd-networkd útvegar. Ef þið virkjið hvorugt hefur markmiðið ekkert að bíða eftir, svo það klárast á þeirri stundu sem eitthvað dregur það inn, sem getur verið löngu áður en DHCP svarar. Röðarlínan í einingunni ykkar var heiðarleg og samt gagnslaus.

Fyrsta spurningin er því ekki hvað einingin ykkar lýsir yfir. Heldur hvort eitthvað á þessari vél sé í raun að sinna biðinni.

Lesið síðustu ræsingu í stað einingaskrárinnar

Einingaskrár lýsa áformum, og dagbókin lýsir því sem gerðist. Biðjið aðeins um þá ræsingu, með einhæfum tímastimplum svo hver skilaboð sitji á einni klukku. Finndu svo tvær línur: stundina þegar göngueiningin byrjaði að ræsast, og stundina þegar talan birtist eða biðþjónustunni lauk. Raðið þessum tveimur tölum og kapphlaupið er annaðhvort staðfest eða útilokað.

Háðleikayfirlitið staðfestir það. Ef mikilvæg keðja fyrir göngueininguna inniheldur enga biðþjónustu, þá seinkaði ekkert á þeirri leið ræsingunni, og markmiðið sinnti ekki þeirri vinnu sem þið gerðuð ráð fyrir. Tvö yfirlit, ein niðurstaða.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Bætið við biðinni, svo nýrri tilraun

Notið drop-in í stað þess að breyta pakkaðri einingu, svo pakkauppfærsla hefni ekki breytingunni hljóðlega. Tvær tilskipanir skipta máli: einingunni verður að vera raðað eftir markmiðinu, og hún verður að draga markmiðið inn í sömu færslu. Röð ein og sér kallar ekki á markmiðið; löngunin gerir það.

Pakkaða eining OpenVPN-biðlarans ber þegar bæði. Handskrifaðar einingar bera venjulega eitt eða ekkert, sem er þess virði að athuga áður en þið bætið einhverju við.

[Service]
Restart=on-failure
RestartSec=15

Hvers vegna fastur svefn er gildra

Svefn í ExecStartPre finnst eins og röðarlagfæring og hagar sér eins og töf með aukaskrefum. Hann hægir á hverri ræsingu, þar á meðal þeim sem voru heilbrigðar, og tapar samt þegar tengingin tekur lengri tíma en talan sem þið völduð.

Verra, hann felur hvort biðþjónustan virkar, svo næsta bilun birtist sem glænýtt vandamál frekar en sama vandamálið með annan tímasetningu. Stutt ræsingartöf er betra tólið: hún kostar ekkert við heilbrigða ræsingu og breytir tapaðri keppni í aðra tilraun. Haldið bilinu hóflegu og leyfið einingunni að takast. Ef hún endurræsist að eilífu er prófíllinn bilaður og engin fjöldi nýrra tilrauna breytir því, svo lesið annálinn í stað þess að hækka bilið.

Þegar röðin er rétt og nöfnin mistakast samt

Virk eining með gönguleið þýðir að röðin sinnti sínu hlutverki og afgangsbilanin er einu lagi ofar. Venjuleg mynd er stilling á leysi sem up-skriftan gagna setur áður en tengingin eða leysirinn var tilbúinn að halda henni. Berið saman stöðu leysisins meðan á biluninni stendur og stöðuna eftir endurræsingu göngueiningarinnar.

Ef endurræsingin lagaði uppflettingar eruð þið með galla í ræsingarröð en ekki rangan DNS-þjón, og þessi tvö þurfa mismunandi lagfæringar. Sannið svo allt saman með köldu ræsingu í stað endurræsingar þjónustu, því endurræsing keyrir gegn neti sem er þegar uppi og mun fela nákvæmlega gallann sem þið eltið. Endurtakið með tengingunni viljandi hægri, og lítið á einingu sem virkar aðeins þegar netið er hratt sem enn bilaða.