Gründe für SIGKILL



  • Hallo!

    Ich habe hier ein Programm, daß nach gut 1 Minute Laufzeit, die sich auf user (40s) und system (4s) aufteilen, automatisch beendet wird.
    Naiv habe ich versucht, mit gdb an die Ursache heranzukommen, allerdings konnte mir der auch nicht weiterhelfen.

    Welche Dienste und Richtlinien in einem Linux System aktiv sind, die eventuell bei zu großer Ressourcenverschwendung einen Prozeß killen?

    Vielen Dank für jede Hilfe,
    Rainer.



  • Linux killt deine Prozesse eigentlich nicht automatisch, wenn er sich in einer Endlosschleife aufhängt. Eine Ausnahme ist es, wenn du in dieser Schleife Speicher reservierst. Dann kann es sein, dass dein Programm den gesamten verfügbaren Speicher auffrist und Linux den Prozess als letzte Rettung für das System killt.



  • Was macht denn das Programm. Wenn's nicht zu groß ist, kannste ja mal Teile davon posten.



  • Steven schrieb:

    Linux killt deine Prozesse eigentlich nicht automatisch, wenn er sich in einer Endlosschleife aufhängt. Eine Ausnahme ist es, wenn du in dieser Schleife Speicher reservierst. Dann kann es sein, dass dein Programm den gesamten verfügbaren Speicher auffrist und Linux den Prozess als letzte Rettung für das System killt.

    Es handelt sich dabei um ein Programm das LEDA, eine Bilbiothek zu graphischen Darstellung von Algorithmen, nutzt. Die Annahme, daß das Programm innerhalb einer Schleife Speicher anfordert, ist richtig. Daran läßt sich aber nichts ändern.

    Habe ich keine Möglichkeit den Fehler abzufangen? Dafür ist doch z.B. bei malloc(...) vorgesehen, daß ein NULL Zeiger zurückkommt! Ich will doch nur sagen können, daß der Speicher alle ist.

    Gruß, Rainer.



  • Es ist ja ok, Speicher in einer Schleife zu reservieren, nur solltest du dich darum kümmern, das diese Schleife nicht endlos vor sich hinwerkelt. Wenn du vergisst, den Speicher freizugeben und dann noch eine Endlosschleife hast, kann es passieren, dass genau dieses Verhalten auftritt:

    • So lange noch genügend Speicher da ist, läuft deine Endlosschleife und frisst nur CPU-Zeit.
    • Wenn dann irgendwann der Speicher ausgeht, wird dein Programm gekillt (OOM-Kill).

    Ja, normalerweise sollte ein fehlgeschlagenes malloc NULL zurückgeben, aber:

    man malloc schrieb:

    Bugs
    By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer. In case Linux is employed under circumstances where it would be less desirable to suddenly lose some randomly picked processes, and moreover the kernel version is sufficiently recent, one can switch off this overcommitting behavior using a command like
    # echo 2 > /proc/sys/vm/overcommit_memory
    See also the kernel Documentation directory, files vm/overcommit-accounting and sysctl/vm.txt.



  • Mein Problem ist halt nun, daß der zu erzeugende Graph sehr groß ist und ich irgendwie einen kontrollierten Absturz hinkriegen will, so daß ich dem Benutzer wenigstens ein "Zuwenig Speicher" entgegen werfen kann.

    Gibt es dazu Möglichkeiten?



  • Wäre mir jetzt keine bekannt.

    Aber vielleicht kann man den Speicherbedarf ja vorher irgendwie ausrechnen oder zumindest überschlagen, so dass man von vornherein weiß, ob es klappt oder nicht.

    Das wär auch für den Anwender besser, sonst wartet er ne Weile und bekommt erst dann mitgeteilt, dass er zuwenig Speicher hat.



  • Als root kannst du dieses Overcommiting ausschalten:

    echo 2 > /proc/sys/vm/overcommit_memory
    

    Außerdem kann ich mich erinnern, dass mir mal eines meiner eigenen Programme in den "Zu wenig Speicher"-Teil gesprungen ist, weil ich mittels man: ulimit ein (zu kleines) Speicherlimit gesetzt habe. Du kannst also mit man: setrlimit auch ein Limit setzen, nur sollte das halt kleiner sein als der verfügbare virtuelle Speicher.



  • Leider kann ich nicht mit Root-Rechten arbeiten.

    Trotzdem vielen Dank.


Anmelden zum Antworten