SLES 11 mit automatischem Prozesskilling?

mathiko

mathiko

Konix
Hallo,
ich habe ein Perlscript, welches mehrere Stunden lang diverse Aufgaben erledigt. Gestartet wird das Script durch ein Cronjob.
Nach mehreren Stunden Laufzeit wird dieses Perlscript aber automatisch beendet. Leider weiß ich nicht warum. Entweder ist der Arbeitsspeicher verbraucht oder mein BS SLES11 hat irgendwelche Dienste, die mir den Prozess nach einem "time-limit" automatisch killen.

Wie könnte ich denn die Ursache identifizieren?
Welche Logfiles sind dafür zuständig? Messages liefert jedenfalls keine Aussagen.
Gibt es Dienste in der SLES, die die laufenden Prozesse kontrollieren?
Wenn der Arbeitsspeicher verbraucht ist, werden dann automatisch die Prozesse gekillt? Sicherlich gibt es Logfiles, die das dokumentieren?

Ich wäre sehr dankbar, wenn mir jemand den einen oder anderen Tipp geben könnte.

Vielen Dank,
MathiKo
 
Es kann sein, dass das Skript gekillt wird, wenn der RAM knapp wird. Auf jeden Fall könntest du einen Signalhandler einbauen, mit dem du loggst welches Signal das Skript bekommt, wenn es stirbt. Ausserdem kann dir Cron eine Email schicken, wenn ein Cronjob unplanmässig beendet wird. Per Default geht diese an den Eigentümer der Crontab, lässt sich aber mit einer MAILTO-Variable am Anfang der Crontab auch an jede beliebige andere Adresse schicken. In der /var/log/warn finden sich auch oft Hinweise, wenn es Probleme mit Cronjobs gibt. Ggf. lässt du aber auch dein Skript mal etwas mehr Output geben und loggst diesen weg, so dass du siehst, ob es evtl. einen Fehler beim Beenden gibt, der im Skript selbst liegt.
 
Wenn der Arbeitsspeicher verbraucht ist, werden dann automatisch die Prozesse gekillt?

Es gibt den sogenannten →oom (out of memory) killer, es scheint mir aber unwahrscheinlich, dass der bei Dir zum Zuge kommt, denn eher werden Prozesse in den swap ausgelagert (Du könntest Dir diese Möglichkeit aber mal näher ansehen, sofern Du keine swap-Partition hast oder diese regelmäßig überläuft). Ich denke auch, dass Du mit einem --verbose-Output bzw. den enstprechenden logfiles der Sache eher auf die Spur kommst.
 
Zurück
Oben