Troubleshooting System Crashes

Hab vor ein paar Wochen/Monaten meine 3 Rasperry PIs entfernt und alles auf einen Intel NUC migriert. Leider hab ich seitdem ziemliche Stabilitätsprobleme und ich komm nicht dahinter was das Problem ist. Das Problem ist, dass der NUC nicht mehr via SSH erreichbar ist und die Services darauf sind auch nicht mehr erreichbar. Da er im Rack steht würd ich gern vermeiden da jetzt alles anzustecken (Display, Keyboard, etc.) - aber wenns nicht vermeidbar ist wäre das der Next Step.

Es laufen eigentlich nur Docker Container darauf - sonst hab ich direkt nicht wirklich was installiert. Alle Container haben Resource Limits vergeben - ein Out of Memory sollte somit eigentlich nicht möglich sein. NUC hat 8GB memory.

Im /var/log/syslog finde ich nichts relevantes - das einzige was öfters auftaucht sind diese Meldungen:

Code:

Jan 30 11:00:02 nuc systemd-networkd[586]: veth954a0cb: Link UP
Jan 30 11:00:02 nuc kernel: [155394.622802] br-5adb154c6088: port 12(veth954a0cb) entered blocking state
Jan 30 11:00:02 nuc kernel: [155394.622811] br-5adb154c6088: port 12(veth954a0cb) entered disabled state
Jan 30 11:00:02 nuc kernel: [155394.622896] device veth954a0cb entered promiscuous mode
Jan 30 11:00:02 nuc dockerd[885]: time="2023-01-30T11:00:02.779603050+01:00" level=info msg="No non-localhost DNS nameservers are left in resolv.conf. Using default external servers: [nameserver 8.8.8.8 nameserver 8.8.4.4]"

Daher meine Vermutung obs irgendeine Netzwerkproblem gibt.

Ein Container könnte evtl. Probleme machen - hab viseron drauf laufen welches ein NVR ist - das reizt das Memory Limit schon aus und verwendet GPU Decoding der Camera Streams. Aber sollte dann nicht nur der Container crashen?

Ich hab auch schon prometheus, node-exporter und grafana drauf laufen - bräuchte aber ein paar Inputs auf was ich da schauen soll weil ich bisher nichts gefunden hab.

OS ist ein Ubuntu 22.10

Hört sich imho nach meinem NUC Problem von Anno 20 an:

https://serverfault.com/questions/6...dware-unit-hang

ethtool -K eno1 gso off gro off tso off hats bei mir gefixt und wurde zum permaworkaround

Hatte auch so Hänger wo die Kisten net erreichbar war.

Ja, daran ist jetzt wohl das FS oder das Blockdevice drunter (oder der Weg der Daten vom Blockdevice in den Hauptspeicher) schuld. Es wundert mich, dass deine Shell forken konnte nach dem SSH-Login - aber da liegt die Binary wohl vollstaendig im Page Cache, und nur "neue" Programme, deren Text nicht im Cache ist, haben das Problem. Mehr koenntest du vielleicht rausfinden, wenn du das Kernel Debug Log anzeigen kannst. Normal macht man das mit `dmesg`, aber das Programm wird das selbe Schicksal ereilt haben, wie die anderen Binaries, die du nicht mehr starten kannst.

Aber man kann sich aus dem, was die Shell alleine mithilfe von Builtins kann, ein rudimentaeres Replacement basteln, und zwar so (als root):

Code:

while read -r i; do echo "msg: $i"; done < /proc/kmsg

Achtung aber! Wenn du das ausfuehrst, kriegst du den Inhalt des Ring Bufers NUR EIN EINZIGES MAL (weil das Lesen auf diese Weise die Inhalte des Buffers leert). Stell also sicher, dass du die Ausgabe an einen sichereren Ort wirst wegkopieren koennen (copypasta ausm Terminal Emulator deines SSH-Clients raus z. B.).

Nein, das kann ganz sicher nicht zu DIESEM Fehler (EIO) fuehren. In dem Fall (afaik braucht der dynamische Linker aber keinen Platz in irgendeinem Dateisystem, um eine ELF-Executable starten zu koennen...) wuerde es zu "No space left on device" (ENOSPC) kommen.

Ok hab endlich ein Display angeschlossen - ist wohl doch ein HW Problem und die SSD ist hinüber....



Zuerst der PI4 diese Woche, jetzt die SSD...hab kein Glück mit HW derzeit...