systemd restart service - hogy működik?

Linux-kezdő

Otthoni (debian) szerveren ddclient segítségével frissítem a dinamikus dns-t (a duckdns-nél, de ez most nem lényeg).

Néha eldobja a kapcsolatot, ekkor a ddclient képes meghalni network unreachable-el:

Jun 16 09:58:01 <xxxxx> ddclient[285088]: WARNING:  cannot connect to www.duckdns.org:80 socket: IO::Socket::INET: Bad hostname 'www.duckdns.org'
Jun 16 09:58:01 <xxxxx> ddclient[285090]: FAILED:   updating <xxxxxxxx>: Could not connect to www.duckdns.org.

A FAILED után pedig a ddclient egyszerűen kilép...

● ddclient.service - Update dynamic domain name service entries
     Loaded: loaded (/lib/systemd/system/ddclient.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:ddclient(8)

A gyanúm a systemd-re vetült, de ebben már nem vagyok biztos. A default unit file (debian: /usr/lib/systemd/system/ddclient.service) beállítás Restart=on-failure

Azaz csak akkor indítja újra, ha az exit code 0-tól különbözik. Én feltételeztem, hogy ennek a FAILED sornak ellenére ezek szerint 0 lehet a visszatérési érték. Hát akkor módosítsuk a unit file-t.

 Az eredeti unit file:

[Unit]
Documentation=man:ddclient(8)
Description=Update dynamic domain name service entries
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/run/ddclient.pid
Environment=daemon_interval=5m
EnvironmentFile=-/etc/default/ddclient
ExecStart=/usr/sbin/ddclient -daemon $daemon_interval -syslog -pid /run/ddclient.pid
Restart=on-failure

[Install]
WantedBy=multi-user.target

A [Service] részbe beleírtam:

Restart=always
RestartSec=5min

Csak a probléma hogy ez nem segített... pont ugyanúgy meghal, és nem indítja újra.

Aki kicsit járatosabb a systemd-ben: tudna segíteni hogy miért nem?

  • 387 megtekintés

( guszti | 2022. 07. 11., h – 07:46 )

Szerkesztve: 2022. 07. 11., h – 07:51

Nem ezt a paramétert kéne kicsit kisebbre venni?

Environment=daemon_interval=5m

Ez itt szerintem 5perces intervallum valamire.

Ja és ez is:

RestartSec=5min

Nekem mondjuk itten az a furcsa hogy egy internetkonfiguralgato tool omlik ossze akkor amikor nincs internet... azert legalabb azok felkeszulhetnenek erre az eshetosegre ;) szoval lehet hogy a ddclient-nel kell es/vagy lenne erdemes finomhangolni a krokodilon. 

( kroozo v | 2022. 07. 11., h – 11:12 )

fel tudod tenni a journalt arról a környékről, mikor megdöglik?

Itt fog kibukni, hogy az általam "Linux-kezdő" topic valójában az én tudásszintemet jelenti csak, nem a téma egyszerűségét :)

Legalábbis ami a systemd-t illeti.

Ha a journal alatt azt értjük, amit a journalctl visszaad (és ami ugyanaz mint a syslog), akkor az a két releváns sor, amit leírtam. Előtte van még egy pppd összeomlás:

Jul 11 03:02:42 <xxxxx> pppd[1114]: LCP terminated by peer (Peer not responding)
Jul 11 03:02:42 <xxxxx> pppd[1114]: Connect time 678.2 minutes.
Jul 11 03:02:42 <xxxxx> pppd[1114]: Sent 192245979 bytes, received 2461732994 bytes.
Jul 11 03:02:43 <xxxxx> pppd[1114]: Modem hangup
Jul 11 03:02:43 <xxxxx> pppd[1114]: Connection terminated.

De az aztán újraindul rendesen.

-- Boot 153fdf3a8b7b435b844f1d61a1c097f5 --
May 13 10:33:19 <xxx> systemd[1]: Starting Update dynamic domain name service entries...
May 13 10:33:19 <xxx> systemd[1]: Started Update dynamic domain name service entries.
May 13 10:33:24 <xxx> ddclient[20939]: SUCCESS:  updating <xxxxxxxxxxxx>: good: IP address set to xx.xx.xx.xx
-- Boot 2df37fb6de394984a46cab8d9dffcf4d --
May 28 19:54:47 <xxx> systemd[1]: Starting Update dynamic domain name service entries...
May 28 19:54:47 <xxx> systemd[1]: Started Update dynamic domain name service entries.
-- Boot 6fb38559cdc04526860f352e1c55fc67 --
Jul 11 05:25:20 <xxx> systemd[1]: Starting Update dynamic domain name service entries...
Jul 11 05:25:20 <xxx> systemd[1]: Started Update dynamic domain name service entries.

Ez még annál is kevesebb információ, mint amit kezdetben megadtam. Az adott időpontban én indítottam újra, kézzel.

Ez minden amit kidob a fenti parancsra. Az időtartományban benne van a mai fail, de a korábbi jún. 16.-os is. Ha tudtok jobb journalctl opciókat, ne tartsátok magatokban.

Ugyanez a "hagyományos" módon (cat /var/log/syslog | grep ddclient VAGY journalctl | grep ddclient):

Jul 10 15:44:34 <xxxx> ddclient[603155]: SUCCESS:  updating <xxxxx>: good: IP address set to xx.xx.xx.xx
Jul 10 15:44:35 <xxxx> ddclient[603155]: SUCCESS:  updating <yyyyy>: good: IP address set to xx.xx.xx.xx
Jul 11 03:03:26 <xxxx> ddclient[618051]: WARNING:  cannot connect to www.duckdns.org:80 socket: IO::Socket::INET: Bad hostname 'www.duckdns.org'
Jul 11 03:03:26 <xxxx> ddclient[618051]: FAILED:   updating <xxxxx>: Could not connect to www.duckdns.org.
Jul 11 05:25:20 <xxxx> ddclient[621218]: WARNING:  file /var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 'ip' = ''
Jul 11 05:25:20 <xxxx> ddclient[621218]: WARNING:  file /var/cache/ddclient/ddclient.cache, line 4: Invalid Value for keyword 'ip' = ''
Jul 11 05:25:20 <xxxx> ddclient[621218]: SUCCESS:  updating <xxxxx>: good: IP address set to xx.xx.xx.xx
Jul 11 05:25:24 <xxxx> ddclient[621218]: SUCCESS:  updating <yyyyy>: good: IP address set to xx.xx.xx.xx

 

A 03:03:26 és 05:25:20 timestamp-ek között indítottam újra kézzel.

Elég furcsa, hogy nincs semmi bejegyzés a systemd-re (iiletve hát a grep ddclienntel nem, de a sima journalctllel igen) Adnál egy 

cat /var/log/syslog | grep -E 'ddclient|systemd'

és/vagy egy

journalctl --since "2022-07-11 03:03:20" --until "2022-07-11 03:03:32"

kimenetet?

Jó lenne látni, hogy a systemd mit gondolt arról a unitról.

( asch v | 2022. 07. 11., h – 11:39 )

Szerkesztve: 2022. 07. 11., h – 11:44

Van még egy opció, ami tud bajt csinálni, szerintem totál nem logikus ennek a defaultja sem: StartLimitIntervalSec

Ez elvileg arra szolgál, hogy megakadályozza, hogy ha valami nem indul el sokszor, akkor már ne is próbálkozzon feleslegesen. De pont például nettől fűggő szolgáltatásra ez csak hibát okoz. Itt van rá megoldás:  https://gist.github.com/Clownfused/1144a4547fc428f7f690cd81b912ac74

(Bár a te példádban az a gyanúm, hogy nem ez lesz a hiba, mert nálad más státusszal áll a szolgáltatás.)

Úgy debuggolnám a problémát, hogy kézzel kilövögetném és megnézném, hogy újraindul-e.

Dinamikus DNS-t egyébként úgy is összerakhatsz, hogy nem állandó szolgáltatásként futtatod, hanem időzítővel indítod el mondjuk 5 percenként vagy még gyakrabban. És akkor megszabadulsz az újraindulás kérdéskörtől. Nekem így működik az itthoni IP címem frissítése a domain névre (godaddy API-n keresztül frissíti be). Valamikor feltettem a routerre és már szinte el is felejtettem, hogy van ilyenem olyan jól működik.

( SzBlackY | 2022. 07. 11., h – 12:01 )

A [Service] részbe beleírtam:

Restart=always
RestartSec=5min

Csak a probléma hogy ez nem segített... pont ugyanúgy meghal, és nem indítja újra.

Aki kicsit járatosabb a systemd-ben: tudna segíteni hogy miért nem?

1. Ilyet ne csinálj, használj override-ot (/etc/systemd/system/ddclient.service.d/local.conf -ba tedd, amit módosítani akarsz, vagy systemctl edit ddclient.service, ott módosítsd)

2. systemctl daemon-reload megvolt? És persze a daemon-reload után kézzel újraindítás és a következő hiba megvárása / szimulálása?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( Friczy v | 2022. 07. 11., h – 15:42 )

Lehet, hogy hülyeség, nem értek a systemd-hez, de ott általában az rémlik, hogy amit a systemd indít, azt nem daemon módban kell indítani.

( batyu v | 2022. 07. 11., h – 18:44 )

Ha a "failed" üzenet után kilép és 0-val, akkor ez kicsit érdekessé teszi a kérdést. Elsőre nem tűnik okos dolognak ha így írták meg, de nem valamilyen konfig beállítás okozza ezt a viselkedést esetleg? Bár ahogy látom a szolgáltató specifikus paraméterek mellett a daemon lenne még ami játszik, de azt meg a unit állítja be kapcsolóval. Abból kiindulva viszont, hogy a konfigban lehet mail-failure= értéket is beállítani gyanús, hogy fail esetén nem kéne kilépnie.

Egyébként duckdnshez van faék egyszerű cron-os megoldás is ami teljesen jól működik, azzal nincs ilyen gond :)

Igen, a systemctl daemon-reload, és a systemctl restart ddclient kell hozzá, anélkül nem megy.

 

A másik, amit én az utóbbi időben nem szoktam, hogy Type=forking esetén PidFile-t adjak meg.

Nem kell, hiszen ekkor a folyamat az ő gyereke, ezért tudja, hogy hol van.

(Volt már hogy megkavarodott nekem a systemd, amikor a pidfile-ben más érték volt, mint ami a processz valódi pidje.)

 

(Csak, hogy a hivatkozott manual is fel legyen tüntetve: https://www.freedesktop.org/software/systemd/man/systemd.service.html )

Bocsánat, valóban nem írtam.

Májusban írtam bele, azóta párszor már volt reboot (aminek még szintén nyomozom az okát, de azt most tekintsük függetlennek).

De ezek szerint a reboot kevés lenne? Meglepne, de tényleg nem vagyok systemd expert.

Mindenesetre ha ennek hinni lehet, akkor ez van most:

# systemctl show ddclient
Type=forking
Restart=always
PIDFile=/run/ddclient.pid
NotifyAccess=none
RestartUSec=5min
...

nem kevés. Ha basztatsz valami unit filet, akkor kell utána egy systemctl daemon-reolad, meg bele kell rúgni a unitba, de nyilván egy restart elég ehhez.

További ötletek:

- Azt nézhetnéd még meg esetleg, hogy a /run/ddclient.pid tartalma egyezik-e most a valóban futó ddclient pidje?

- Meg hogy nincs-e valami contadicting az /etc/ddclient.conf-ban