Geplanter Runaway-Job

Ein geplanter Job feuert, wird nicht fertig und hält die CPU auf 100 %. Es ist der einzige Vorfall, der wiederkommt, nachdem du dich um ihn gekümmert hast – denn sich um den Prozess zu kümmern ist nicht dasselbe, wie sich um den Zeitplan zu kümmern.

Was er tut

Auf der Zielmaschine gerät die CPU in die Sättigung: WARN, dann CRIT, und die Verfügbarkeit (Uptime) rutscht mit. Der Job ist ein benannter Prozess und erscheint mit seiner PID in der Ausgabe von top; die Diagnose ist also nicht der schwierige Teil.

Der schwierige Teil ist, dass der Scheduler noch lebt. Du stoppst den Prozess, und dieselbe Vorfallinstanz startet ihn kurz darauf erneut. Das tut sie eine begrenzte Anzahl von Malen, bis sich das Zeitfenster des Jobs von selbst schließt – die Nacht, die du damit verbringst, dich immer wieder darum zu kümmern, endet also tatsächlich, aber sie endet, weil dem Job die Geduld ausgegangen ist, nicht weil du etwas gelöst hast; die abschließende Log-Zeile sagt genau das.

Die Log-Signatur

Im Cron-Log startet ein Job, und dann zeigt monit denselben Namen über der CPU-Schwelle:

03:02:15 db-01 CRON[24310]: (root) CMD (/opt/jobs/backup.sh)
03:02:51 db-01 monit[588]: 'backup.sh' cpu usage of 100% matches resource limit [cpu usage > 80.0%]
03:03:40 db-01 monit[588]: 'db-01' cpu usage of 98% matches resource limit [cpu usage > 90.0%]

Das Timing gehört zur Signatur. Dieser Vorfall landet tendenziell mitten in der Schicht, gegen 03:00 – genau dann, wenn sich ein echtes Backup-Fenster öffnen würde. Den Prozess findest du mit top; wer ihn gestartet hat, steht in ps und in den Cron-Einträgen.

Wenn du ihn in Ruhe lässt

Anhaltende CPU-Sättigung auf einer einzelnen Maschine und die SLA-Schuld, die ein ungelöster Vorfall mit sich bringt. Er ist überlebbar – die Maschine geht nicht von selbst auf DOWN –, aber er blutet Verfügbarkeit aus, solange er läuft.

Abgrenzung

Wann er auftaucht