Node startet bei update abrupt neu

[badsmoke]

Hallo,

ich hatte jetzt schon mindestens zwei mal das Problem, das sich ein node bei einem ganz normal packages update abrupt neustartete.

das ist letzte Woche schon mal passiert, es hat also nichts mit dem update auf 7.3 zu tun

letzte kern.log zeile

`Nov 23 19:09:11 trick kernel: [284729.942724] watchdog: watchdog0: watchdog did not stop!`


syslog und term logs sind im Anhang



zum System selber

EPYC Cluster mit 3 Nodes

Node 1 AMD EPYC 7452
Node 2 AMD EPYC 7453 <--- um den gehts
Node 3 AMD EPYC 7301


bei den anderen beiden ist kein Problem aufgetreten

Proxmox Version 7.2-1


danke schon mal


logs sind noch alle Vorhanden, wenn noch was gebraucht wird

 

[Björn Lässig]

Ich habe hier 3 AMD EPYC 7401P und bei mir ist das heute auch aufgetreten.

Bei mir passiert das, wenn der Dienst 'watchdog-mux' vom needrestart neu gestartet wird.
Das ist irgendwie neu und vorher noch nie aufgetreten. Das war eine große Überraschung.

 

[UdoB]

Bei mir passiert das, wenn der Dienst 'watchdog-mux' vom needrestart neu gestartet wird.

Das muss ich bestätigen, es ist mir vor ca. 2 Monaten ebenfalls passiert, auf EPYC 7443.
Seitdem traue ich mich nicht mehr, den watchdog zu restarten...

 

[t.lamprecht]

Der watchdog-mux soll und darf auch nicht einfach restartet werden, Proxmox VE hat extra handling dafür, dass das beim Upgrade eben nicht automatisch gemacht wird, etwa ein Restart=no im systemd Service File und Ausnahme in debian postinst für upgrades.
Wenn needrestart sowas ignoriert und da dazwischen funkt können wir nichts dafür; eine "whitelist" Funktionalität fehlt dem needrestart Tool anscheinend noch (gibt offenes issue upstream).

Das needsrestart Tool ist mMn nach auch etwas irreführend benannt; kein Service benötigt einen restart (unbedingt) - das wird normal über apt/dpkg triggers gehandlet falls wirklich nötig...

 

[Björn Lässig]

Der watchdog-mux soll und darf auch nicht einfach restartet werden, Proxmox VE hat extra handling dafür, dass das beim Upgrade eben nicht automatisch gemacht wird, etwa ein Restart=no im systemd Service File und Ausnahme in debian postinst für upgrades.
Wenn needrestart sowas ignoriert und da dazwischen funkt können wir nichts dafür; eine "whitelist" Funktionalität fehlt dem needrestart Tool anscheinend noch (gibt offenes issue upstream).

Das needsrestart Tool ist mMn nach auch etwas irreführend benannt; kein Service benötigt einen restart (unbedingt) - das wird normal über apt/dpkg triggers gehandlet falls wirklich nötig...

Needrestart startet Services neu, die zB gelöschte/ersetzte Bibliotheken benutzen. Ein Bibliotheksupdate ist nutzlos, wenn man noch den alten Stand verwendet. Wenn needrestart etwas neu starten will, dann heißt dass, das die deployte Version von etwas gar nicht verwendet wird.

needrestart kennt blacklists:

#/etc/needrestart/conf.d/blacklist.watchdog-mux.conf

# disable restart of watchdog-mux cause they shutdown the system
$nrconf{override_rc}->{q(^watchdog-mux)} = 0;

Das löst das Problem erst mal.
Hätte ich das OOMScoreAdjust=-1000 und Restart=no eher gesehen wäre mir das nicht passiert.

 

[UdoB]

Der watchdog-mux soll und darf auch nicht einfach restartet werden

Okay, danke für diese Aussage! Da sich nach meiner Erfahrung alle anderen Dienste problemlos restarten lassen, war das Verhalten (für mich) jedenfalls überraschend...

Insgesamt gibt es ja mehr als ein Dutzend "pve*"-Services (mit -banner und -update.timer anscheinend 18). Eine tabellarische Darstellung der Effekte und Risiken beim fehlen eines Dienstes oder beim Restart eines Dienstes wäre hilfreich. Vielleicht als vervollständigende Ergänzung zu https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_service_daemons

Viele Grüße

 

[badsmoke]

Ok alles klar danke für die Rückmeldungen, ich hab das von Björn Lässig jetzt auch eingestellt.