Dotaz: start openvpn clienta po padu

[chinook]

Zdravím, PC s debian 10, které běží nonstop je připojeno na VPNserver. Bohužel jednou za cca měsíc se stane, že openVPN spadne. Jak řešit, aby zase naběhl a nemusel ručně nahazovat příkazem:

systemctl start openvpn@vpnclient.service

Nemohu se pak k PC připojit a musím tam zajet a nahodit OpenVPN.

Předem děkuji za rady

Odpovědi

[Max]

Pokud ti padá služba, můžeš si v rámci systemd nastavit, aby se po pádu znovu spustila. To se řeší takto:

...
[Service]
Restart=on-failure
RestartSec=5s
...

resp. ještě lépe použít "always":

...
[Service]
Restart=always
RestartSec=5s
...

Zdar Max

[chinook]

Myslíš tento soubor?

/run/systemd/generator/openvpn.service.wants/openvpn@vpnclient.service

Tam mám 
...
[Service]
RestartSec=5s
Restart=on-failure

změnit tedy na always a restartovat službu?

[Josef Kufner]

systemctl edit openvpn@vpnclient.service

[Max]

Nikdy se needitují systemd unity natvrdo. Pokud tedy nevytváříš svojí vlastní přímo v etc. Vždy přes "systemctl edit unita" nebo "systemctl edit --full unita"
Zdar Max

[Pavel 'TIGER' Růžička]

Teď si tu trošku pobrečím. Kam se vytrácí ta jednoduchost Linuxu? Není tomu tak dávno, kdy na konfiguraci celého systému stačil jeden textový editor. Teď je potřeba znát už i příkazy pro editaci ...

[Jendа]

Mně ten příkaz spustí textový editor se souborem /etc/systemd/system/něco, který si můžeš vytvořit i sám, jenom pak možná budeš muset udělat daemon-reload. Jinak nikdo ti nebrání editovat přímo ten originální soubor - ale to pak vede přesně k těm situacím, kdy při upgradu řešíš konflikty, když se ten původní soubor v upstreamu změnil.

[Pavel 'TIGER' Růžička]

On i ten crontab -e ti spustí ten textový editor s otevřeným konfigurákem, jen ta syntaxe příkazu je zase jiná ...

[Max]

systemd není tak špatný, řeší spoustu věcí. A jednou z těch věcí je i úprava systémových unit. V etc máš symlinky do systémových adresářů, které se aktualizují v rámci balíčků. Když tu unitu natvrdo změníš, tak se updatem zase vrátí zpět. Můžeš to vyřešit tak, že tu unitu deaktivuješ, nakopíruješ do etc a ručně změníš. Tím si ale můžeš něco poškodit při upgrade OS a budeš zase řešit další problém. Když uděláš úpravu unity pomocí "systemctl edit unita", tak se ti vygeneruje separé konfigurák jen s tím rozdílem a je nadřazen, takže přepisuje ten původní, který se může v průběhu času měnit s aktualizací OS. Přepisovací soubor se vždy vygeneruje do cesty:

/etc/systemd/system/jmeno_unity.d/override.conf

Je to systémové řešení, jednotné, přehledné, když po někom přebereš správu, tak jednodušeji zjistíš změny (pokud to není nějaký bastlíř) atd. Navíc systemd řeší i to hlídání běhu služeb, takže kdyby předřečník neměl systemd, tak mu nestačí jeden řádek v unitě, ale musel by si napsat script, který bude kontrolovat, zda openvpn žije a nahazovat ho.
Ano, systemd přidává nějakou úroveň složitosti oproti sysv initu apod., ale podle mě jen zanedbatelně a vesměs jde jen o zvyknutí si na něco jiného.
Zdar Max

[Max]

Jinak doplním, že "on-failure" je v případě, že ten proces padne na hubu. Pokud chcípne vpn tunel, tak se podle mě openvpn ukončí regulérně a neskončí jako failed. Tím pádem nemůžeš použít "on-failure", ale "always". To jen tak na vysvětlenou, jaký je v tom rozdíl.
Zdar Max

[Jendа]

Tady je podobný bug, zkontroluj si jestli to není notify, případně jestli má správně nastavený restart jak píše Max.

[marek]

Dobry den.

Ja to resim nesystemove, ale vcelku UNIXove:

root# crontab -l
0,5,10,15,20,25,30,35,40,45,50,55 * * * * ping -c1 172.26.0.1 || systemctl restart openvpn-client@mojevpn.service
root#

Vyhodou je, ze ten restart se vynuti jeste drive, nez si vpn vsimne, ze je rozpadla. Pingam totiz na druhou stranu vpn a kdyz neprijde odpoved restartuji.

Marek

[Jendа]

openvpn má keepalive, které se určitě běžně nastavuje na míň než 5 minut.

[marek]

jak rikam nesystemove....

Ale zase to pouzivam uz > 15 let, jeste s /etc/init.d/openvpn-cosi restart.

A koncept ze hlida dostupnost nejaka jina sluzba, nez ji zajistuje, je proste takove strategictejsi.

Takze i kdyz se proces openvpn dostane do nejakeho pastavu, stejne se sluzba restartuje.

Samozrejme musi clovek pocitat, ze pak nejde vpn systemove vypnout...

Ono by to slo samozrejme udelat pomoci vlastnosti systemd:

WatchdogSec=300
Restart=always
NotifyAccess=all

a posilat mu z jineho procesu notifikace.

Ale bylo by to proti jedne radce v cronu takove slozite...

Obzvlaste, kdyz to vypadava 2*rocne.

marek

[Jendа]

Já to chápu a sám jsem i tady kdysi psal, že to tak používám (i když já tedy typicky dělám "while sleep 30; do ...; done" ve screenu). Právě v kontrastu s tím odkazovaným bugem v Debianu/systemd unitě -- na tomhle (nebo tvém cronu) se v podstatě nemá co rozbít, zatímco ta systemd unita se pokazila v okamžiku, kdy po výpadku proudu v celém okolí (tj. i protistrana mikrovlnného pojítka) openvpn stihlo najet a vytimeoutovat (neposlalo notifikaci) rychleji než se stihlo navázat mikrovlnné pojítko. No a výsledkem byl běžící počítač na střeše, kde openvpn unita byla ve "failed state" a nikdo ji nerestartoval a co jako teď s tím (naštěstí to bylo na střeše u zákazníka s nízkým očekáváním, takže jsme ho poslali to otočit ručně). Tohle je navíc věc co tě nejspíš nenapadne na stole otestovat - samozřejmě vyzkoušíš, že to jede po power cycle, ale vyzkoušet i to že to najede když se po power cycle zdrží připojení k internetu o 2 minuty?

Rozporoval jsem jen to, že si tvoje řešení všimne rozpadlého spojení rychleji než samotná openvpn. Openvpn posílá tunelem keepalive pakety samo a když přestanou chodit, tak spojení restartuje.