[Wanninger]

In letzter Zeit passiert es immer öfter, dass meine MLDs plötzlich ihren Dienst einstellen.
Nach genauerer Untersuchung hat sich dann heraus gestellt, dass immer wieder mal
der oom-killer zuschlägt und einen Task nach dem anderen tötet. Das geht solange,
bis halt eben nichts mehr geht.

Leider habe ich es bisher noch nicht endgültig klären können, wer der eigentliche
Verursacher des oom's ist, deshalb...

...habe ich ein kleines Startskript gemacht, das zur Bootzeit zwei Kernelparameter so
einstellt, dass im Fall eines oom's, ein Kernel "panic" ausgelöst wird und dieser wiederum
nach 10 Sekunden, einen automatischen "Reboot" startet . Dadurch bleibt der VDR
wenigstens nutzbar und muss nicht immer per Hand rebootet werden.

Wenn's jemand braucht, einfach nach "/etc/init.d/oom" kopieren und rebooten.
Im Anhang sind die Dateien auch mal gepackt drin. Es ist zusätzlich ein Binary enthalten,
mit dem man die Funktion testen kann "/usr/local/bin/oom-test". oom-test krallt
sich so lange 10MB Blöcke bis der Speicher restlos verbraucht ist.

Code: [Select]

#!/bin/sh
#
# Reboot on oom

case "$1" in
        start)
                . /etc/init.d/rc.functions
                echo "Setting Reboot on oom auf 1"
                echo 1 > /proc/sys/vm/panic_on_oom
                echo 10 > /proc/sys/kernel/panic
                check_status
                ;;
        stop)
                . /etc/init.d/rc.functions
                echo "Setting Reboot on oom auf 0"
                echo 0 > /proc/sys/vm/panic_on_oom
                echo 0 > /proc/sys/kernel/panic
                check_status
                ;;
        init)
                start=1
                ;;
        *)
                echo "Usage $0 {start | stop}" >&2
                exit 1
esac

-Wanninger

[baltic]

Hallo,

um welche Maschine(n) handelt es sich denn konkret?

Hast Du mal regelmäßig mit "top" geschaut, welche Prozesse den meisten Speicher verbrauchen? Denn da sollte sich schon im Vorfeld etwas ankündigen. Könntest Du swap-Speicher einrichten?

Gruß
baltic

[Wanninger]

@baltic

Ich kann es zwar nicht verifizieren, aber "gefühlt" habe ich das Problem erst, seit dem vor einigen
Wochen (ca. Mai/Juni - weiß nicht genau wann) nach längerer Zeit, wieder umfangreichere Updates kamen.
Auf jeden Fall scheint es irgendwie mit xorg für Intel zusammen zu hängen, denn davon überschlagen sich
die Meldungen im dmesg ebenfalls und die haben sogar schon zu richtigen Blockaden geführt, wo dann
nur noch ein Power off/on half. Die gab es jedenfalls vorher nie und diese Z83 laufen inzwischen seit fast
einem Jahr bei mir.

Es sind drei Intel Z83 Minirechner mit 4G RAM, die dieses Phänomen mehr oder weniger oft zeigen.

Ich habe auch schon über zwei ssh Sitzungen versucht, mit einer "while...do...done" Schleife für "dmesg"
im einen Fenster und mit "htop" im anderen Fenster, Genaueres heraus zu bekommen, aber leider lässt
es sich bis jetzt nicht wirklich greifen. Es sind auch jedes mal andere Tasks, mit denen der oom-killer beginnt.

So wie es aussieht, scheint es nicht schleichend sondern plötzlich und massiv aufzutreten.

Mich hat es halt genervt, weil ausgerechnet der Wohnzimmer MLD davon betroffen ist. Und wenn der
ein Problem hat und ich nicht zeitnah greifbar bin, gibt's bloß wieder Mecker vom Meister.

--> Deshalb Reboot nach oom...

Wobei, genau genommen würde es sowieso nicht schaden, denn nach einem oom ist ein Reboot
in jedem Fall zu empfehlen. Meist geht ja eh nichts mehr, wenn der Fehler auftritt...

Gruß Wanninger

---

[baltic]

Um Dein Gefühl zu verifizieren, könntest Du ja mal einen älteren Snapshot einspielen und schauen, ob der Dein Problem löst.
Nicht dass am Ende ein HW-Problem besteht (evtl. Überhitzung) und der Effekt nur zufällig zu der Zeit des Updates auftrat.

Prüfe auch, ob die Systemtemperaturen vergleichbar sind und die Stromsparmechanismen in der neueren MLD-Version greifen.

Gruß
baltic

[Wanninger]

Ich hatte schon mal ein Snapshot vom 24.04.2019 eine Woche lang laufen - ist nix passiert.
Dann habe von da aus wieder upgedatet und es kamen diese xorg/softhddevice Fehler im dmesg.
Auch die gelegentlichen harten Hänger traten dann auf, aber ich kann nicht sagen, wann sich
der oom eingeschlichen hat. Ich werd's einfach nochmal ausprobieren.

-Wanninger

---

[clausmuus]

Es muss nicht unbedingt ein Prozess sein, der den Speicher aufbraucht. Zu viele Logs können eventuell auch schuld sein, denn per voreinstellung landen die Logs in der RAM-Disk. Wenn insgesamt nicht all zu viel RAM zur Verfügung steht könnte das eventuell die Speicherknappheit erklären.
Zum testen könntest Du das Logging einen Level höher stellen so das auf die HDD geloggt wird. Eventuell hilft's auch das logging ganz abzuschalten, das betrifft aber nicht alle Logfiles und somit eventuell nicht das schädliche.