Esetleges systemd hiba

Debian GNU/Linux

Egy minimális debian virtuális szerveren a következő mágikus hibaüzenetekkel van tele a log:

Dec 19 04:15:24 monitor systemd[1]: Failed to start Cleanup of Temporary Directories.
Dec 19 04:15:24 monitor systemd[1]: systemd-tmpfiles-clean.service: Failed with result 'resources'.
Dec 19 04:15:24 monitor systemd[1]: systemd-tmpfiles-clean.service: Start request repeated too quickly.

A szép benne, hogy esetleges. Ha van, akkor zsákszámra, de néha nincs.

Egyébként minden rendben működik. Sehol máshol semmilyen más hibát nem látok.

A szerveren csak egy icinga és egy pdns fut. Hogy mi igazán a probléma, arra nem jöttem rá. A legjobb javítási ötlet az volt, hogy emeljem fel a system.conf-ban az engedélyezett újraindítások számát, amit ugye miért is? Meg mit is akarna újraindítani a systemd ennyiszer? És miért is? Vagyis is mi is a hiba?

Tehát eléggé tanácstalanul állok ezek előtt a naplóbejegyzések előtt. Leginkább arra tippelek, hogy ez is egy a sokat emlegetett systemd bugok közül, de akkor mi lehetne a megoldás?

Ha van ötletetek, örömmel kipróbálnám, mert így már a tárterület 80%-át ezek a logok eszik fel.
 

  • 553 megtekintés

( NevemTeve | 2020. 12. 19., szo – 06:46 )

Két ötletem lenne: egyrészt selinux (vagy hasonló segítőprogram) kikapcsolása, másrészt `strace -f -p $(pidof systemd) 2>/tmp/log.systemd` szerű paranccsal debuggolni. Jó esetben lesz ott értelmes errno érték valamilyen unlink-nél.

( Polesz v | 2020. 12. 19., szo – 07:30 )

Állítsd le a systemd-tmpfiles-clean.service-t, aztán nézd meg melyik csomaghoz tartozik. Egyébként szerintem egy elbaltázott bejegyzés okozza az anomáliát, név szerint valami resources amit nem jól dolgoz fel.

Ez jó ötlet volt. Már csak azért is, mert nem is fut ilyen service.

A systemctl --type=service listában egyáltalán nem is szerepel, bár a /lib/systemd/system/systemd-tmpfiles-clean.service fájl létezik. Igaz, van systemd-tmpfiles-setup.service és systemd-tmpfiles-setup-dev.service a listán. Állítsam le ezeket?

Ami ennél is szomorúbb, hogy több service mellett is ott állt a failed státusz. (Pl.: systemd-logind.service, systemd-random-seed.service, ...). Ez egy reboot után megszűnt.

Mivel egy alap stable debian telepítésről van szó, amint csak az icinga és pdo csomagok lettek felhúzva, motoszkál bennem a kérdés, hogy nem lehet-e ennek az egésznek a hátterében, maga a vitruális gép, amint fut?

Igen, ott van, és egy olyan systemd-s szolgáltatás, ami nem állandóan fut, hanem ütemező indítja megfelelő körülmények esetén, majd a lefutása után kilép. A "service" itt picit több, illetve más, mint amit sysvinit esetén megszoktunk. Ez a szolgáltatás átmeneti fájlokat/könyvtárakat takarít, megadott konfigurációs paraméterek alapján. Ha az alkalmazásod fel van rá készítve, akkor nem cronjob-ot kell írnod rá, scripttel, miegyébbel, hogy az app temp könyvtárát pucolja, hanem egy beállítófájlt kell adnond ennek a service-nek, és az megcsinálja, egységesen, egy kódbázissal, nem pedig alkalmazásonként egyedi scriptekkel.

Ezért volt idézőjelben. Ez nem egy cron által futtatott valami, hanem egy systemd szolgáltatás, amit egy sytemd timer unit indít el:

$ systemctl status systemd-tmpfiles-clean.service
● systemd-tmpfiles-clean.service - Cleanup of Temporary Directories
    Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static)
    Active: inactive (dead) since Mon 2020-12-21 12:41:44 CET; 2h 13min ago
TriggeredBy: ● systemd-tmpfiles-clean.timer
      Docs: man:tmpfiles.d(5)
            man:systemd-tmpfiles(8)
   Process: 656044 ExecStart=/usr/bin/systemd-tmpfiles --clean (code=exited, status=0/SUCCESS)
  Main PID: 656044 (code=exited, status=0/SUCCESS)

dec 21 12:41:43 superior systemd[1]: Starting Cleanup of Temporary Directories...
dec 21 12:41:44 superior systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
dec 21 12:41:44 superior systemd[1]: Finished Cleanup of Temporary Directories.
 

Ebből egész jól látszik, hogy a systemd-tempfiles-clean.timer indítja, meg az is, hogy valójában min volt a processz, ami futott. Természetesen a timer unitnak is van státusza, illetve lehet mondani neki egy systemctl list-timers timer-nevét, ami elmeséli, hogy mikor volt utoljára, mikor lesz legközelebb, ilyesmit. A systemd magától tudja ezt, szépen integrálva a többi részével (pl ráindítania függőségekre, ha kellene, leállítaná őket, ha kellene, nem hagy ráfutni egyiket a másikra, ilyesmi), szóval azért látszik servicenek, mert az. És azért nem fut folyamatosan, mert egy oneshot service, ami elindul, aztán ha megáll, akkor kész.

raadasul lehet olyan szenario, hogy tobbfele idopontban kell valami elinditani (az unix cronnak is megvan a maga korlatja: pl induljon 6:37-kor meg 7:42-kor), ilyenkor 1 service+tobb timer felallas van, illetve a fuggosegeket konnyebb kezelni, mert az mar meglevo codebase.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( kroozo v | 2020. 12. 19., szo – 09:37 )

Azért mielőtt eljutunk odáig, hogy úristenjajjbugossystemd, felmerült benned esetleg, hogy, nem is tudom, pl megnézd alaposabban az emlegetett szolgáltatást?

( zeller | 2020. 12. 19., szo – 12:20 )

Szerkesztve: 2020. 12. 19., szo – 12:22

Amikor ez előfordul, akkor a systemctl status systemd-tmpfiles-clean.service mit mond, iletve a journalctl kimenetében mit látsz a systemd-tmpfiles -hez kapcsolódóan? Szinte biztso, hogy ott lesz a logban, hogymi fáj neki (pl. egy olyan könyvtár, amit az alkalmazás, ami szeretné, hogy a szemetét a systemd rendszeresen purgálja, nem hozott még létre, vagy hasonlók, lásd a /usr/lib/tmpfiles.d illetve /etc/tmpfiles.d/ alatti beállítófájlokat).

Elkezdtem jobban figyelni, mit csinál. 3 service vált gyakran faild állapotra, bár ettől még fut rendesen: apache2, icinga, random-seed.

systemctl status systemd-tmpfiles-clean.service kimenete:

● systemd-random-seed.service - Load/Save Random Seed
   Loaded: loaded (/lib/systemd/system/systemd-random-seed.service; static; vendor preset: enabled)
   Active: failed (Result: timeout) since Sun 2020-12-27 22:39:28 CET; 1 day 9h ago
     Docs: man:systemd-random-seed.service(8)
           man:random(4)
  Process: 208 ExecStart=/lib/systemd/systemd-random-seed load (code=killed, signal=TERM)
 Main PID: 208 (code=killed, signal=TERM)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Megnéztem, mi történt 1 nap 9 órával előtte. A load felszaladt, mert a lemezre várakozott. Az avio értéke 2869ms. :)

Úgy tűnik, ezek a faild állapotok mindig a load megfutása után jönnek elő. De nincs igazán olyan szoftver a gépen, ami terhelésugrást okozná, ezért ismét a virtualizációra gyanakszom. (Más, hasonló méretű virtuális gépeim más környezetben még sosem okoztak ilyen hibát.) Van, hogy napokig semmi, van, hogy egy nap kétszer is lelassul. (Talán a többi virtualizáció függvénye?) Ez igazán nem is lenne baj, hisz egy systemd-nek nem kellene összefosnia magát attól, hogy a rendszer lelassul alatta pár percre.

Az igazi problémám még mindig az, hogy a systemd miért timeout-ol? Hogyan tudnám úgy beállítani, hogy ne tegye ezt? Milyen logot nézzek még, hogy többet tudjak kideríteni?

( solt87 | 2020. 12. 19., szo – 13:00 )

Failed with result 'resources'.

Ennél jobban már csak az olyan, rendkívül hasznos systemd-s üzeneteket szeretem, mint hogy ~"Error: foo.service exited with $exit_status" meg ~"Error: process bar returned $return_result". Még szerencse, hogy profi enterspályz cuccról van szó. =)

Pont a minap egy buster clean install-nal adtam egy eselyt ujra ennek. Hat, ha clean install utan meg mindig tobb a systemd-fail egy boot utan mint a success, akkor ez meg messze van a hasznalhatotol. Szerencsere par percen belul visszamaszott a sysvinit - ami pontosan annyi fail-lal bootolt be mint amennyi egy clean install utan illik. 

De hogy a problémákat mi okozta, azt nem nézted meg... Pedig sok-sok olyan van, ami a systemd szolgáltatásait használni akaró alkalmazások hibája, vagy épp az a gond, hogy sysvinit-es initscripttel indul valami - de sz@rul, és az sysvinit esetén nem derül ki, systemd esetén meg igen.

Mondom: clean install. Asszem az egyetlen dolog amit meg feltettem az egy `mc` volt (lasd: "munkaeszkoz" definicioja), azon kivul semmi. De azert azt nehezen hiszem el hogy egy `mc` igy megboritana barmit, foleg hogy eleg messze van a service-jellegtol :) Szoval igen, kicsit ez a "valaki a forgalommal szemben megy" - "egyvalaki? mindenki!" esetre emelekeztetne.

Tudjuk tudjuk. Ha a systemd-vel van valami, akkor az nem a systemd hibája, hanem a körülötte lévő osszesurusodott valosage, ami próbálja megfojtani. De remélem hamarosan kijavítják a világot, hogy a systemd flawless legyen. Ja bocs az most is az...de ez a fránya világ....

Tudod, egy kicsit azért szórakoztató a valami szolgáltatás szarul indul el, nem tudom mi lehet a baj topic, ahol az már kiderült, hogy a systemd szar, rögtön a topicnyitóban, az első! hozzászólás stracelni akarja az egész systemdt (facepalm), auditlog nézegetés nélkül ki akarja kapcsolni a selinuxot  (double facepalm), de 12 óra alatt egy istenverte `systemctl status systemd-tmpfiles-clean.service` meg egy `journalctl -u systemd-tmpfiles-clean.service`, na az nem sikerült. Aminek kb a csuklóból érkező reakciónak kellett volna lenni topiknyitás helyett. De természetesen biztosan megint a systemd szar.

Igen. Másokat is láttam már, én is csinálom rendszeresen, sőt, ha nagyon meg vagyok szorulva, még egy gdbt is ráaggatok, vagy nézegetek coredumpokat. Sőt, hálózatot is rendszeresen nézek kábelcápával. (Sőt, egyszer egy kolléga hetekig nem beszélt velem, amikor egy ss7tracet dekódolatlanul taileltem, és mondtam meg neki 5 perc alatt a hibát, amit órák óta keresett). Ez semmit nem változtat azon, hogy előbb megnézzük az alap dolgokat. Pl megkérdezzük a systemdt a státuszról, megnézzük a logokat, megnézzük, hogy egyáltalán mi akar ott futni, ha tudjuk, akkor célzottan arra nézünk rá, stb. Nem kezdjük el lendületből stracelni a pid1-et, ha akármi bajunk van.

Egyébként sokkal. A kódból azért könnyebb megsejteni, hogy mi akart történni, mintha tippelgetni kell az alapján, hogy látod hibára futott syscallokat. Főleg egy service managernél, ahol a rendes üzletmenet része, hogy mindenféle hibákat kezelünk, és ezért black box üzemmódban egyáltalán nem triviális eldönteni, hogy ebből melyik miatt futott aztán valójában lukra valami.

De még mindig ott tartunk, hogy van egy generikus, és igen, kretén" error a systemd felügyeletétől, de még mindig csesztünk megnézni, hogy egyébként pl írt-e ki valamit a konkrét szolgáltatás. Ehelyett már jól szórakozunk azon, hogy jajjdeszar a systemd, hát nézd meg.

Nem ezt mondtam, hanem azt, hogy nagyon sok olyan hiba van, ami a sysvinit-esként meghagyott borzadmány initscriptek systemd-s indítása során problémát okoz. Érdekes módon nekem RHEL/CentOS vonalon a telepítés után sem, meg máskor se szórja az error-okat a systemd - illetve ha igen, annak megvan az oka: jellemzően beállítási vagy sysvinit-es örökségként kapott app hibája.

( NevemTeve | 2020. 12. 21., h – 16:17 )

Örülök, hogy megoldódott. Vagy ha nem oldódott meg, akkor érdektelenné vált.