Vorschläge zum Debuggen, warum ps -ef stecken bleibt

7

Einige meiner Prozesse verbrauchen 100% CPU. Ich versuche herauszufinden, welche Skripte es verursachen

Ich habe versucht zu laufen strace ps -ef:

open("/proc/PID/status", O_RDONLY) = 6
read(6, "Name:\textract\nState:\tR (running)"..., 1023) = 1023
close(6) = 0
open("/proc/PID/cmdline", O_RDONLY) = 6
read(6,

Es bleibt also beim Lesen hängen /proc/PID/cmdline. Ich habe versucht, das zu cattun, und es blieb wieder hängen. Offensichtlich ist etwas im Kernel verschraubt; Was soll ich als nächstes versuchen?

Hinweis: Ein Neustart funktioniert nicht. Wenn ich das System manuell herunterfahre, beginnt das Problem erneut. Ich verwende SUSE Linux Enterprise Server 11 (x86_64), Linux 2.6.27.19

Bearbeiten : ps -eErzeugt eine Ausgabe, und ich habe festgestellt, dass es zu viele greps gibt. Die Anzahl der greps variiert: 250, 450, und jetzt sehe ich ungefähr 520 Greps. Ich ging zurück und stellte fest, dass es das Ergebnis eines Cron-Skripts ist. Ich muss diese Cron-Skripte noch verstehen. Ja, topzeigt Ergebnisse an. Wir haben den Server vor 2 Tagen manuell heruntergefahren. Das System wurde in den letzten 2 Tagen ausgeführt. Ich sehe die ganze Zeit einige Orakel-Sachen laufen. Ich habe gerade den Speichertest durchgeführt, keine Fehler festgestellt

— 72616b657368
quelle

Welche Distribution und Version? Welche Kernel-Version? Welche Architektur? Hat ps -eerzeugen Ausgang? Was ist mit top? Läuft dieses System schon lange, was läuft es normalerweise? Haben Sie kürzlich einen Gedächtnistest durchgeführt? Nicht lesen zu können, /proc/$pid/cmdlinesieht aus wie ein Kernel-Bug oder ein Exploit.

— Gilles 'SO - hör auf böse zu sein'

Welche Prozesse verbrauchen die meiste CPU? Der Haufen Greps? Vielleicht ist das Schwein eine schlecht geschriebene Anfrage an Oracle?

— vonbrand

1

Hatte das erst gestern. Das Problem war, dass sich ein Prozess im Zustand "unterbrechungsfreier Schlaf" befand, der oben als Status D angezeigt wurde . ls / proc / kehrt nicht zurück und kann nicht abgebrochen werden. ps -ef kehrt nicht zurück und kann nicht abgebrochen werden.

Wenn ein Neustart nicht hilft, haben Sie wahrscheinlich einen fehlerhaften Sektor auf Ihrer DVD oder Festplatte und die Prozess-PID versucht dort während des Startvorgangs zu lesen. Ein technischer Neustart hilft also, aber der Fehler tritt automatisch erneut auf.

Überprüfen Sie mit oben, ob sich der Prozess tatsächlich im Status D befindet, und fahren Sie dann fort. Starten Sie den Computer, ohne diesen Prozess aufzurufen (Rettungssystem). Starten Sie dann das Programm, das es strafft, und sehen Sie, auf welche Dateien es zugreift. Ich wette, eine Datei hat schlechte Sektoren.

— Thorsten Staerk
quelle

0

Es sieht so aus, als ob grep hängen bleibt und aufgrund der Cron-Job-Planung nach einer bestimmten Zeit ein anderer Prozess aktiv wird (wie in crontab geschrieben). Mehrere Prozesse führen zu einem nicht reagierenden System

Versuchen Sie folgende Debugging-Methode:

Ändern Sie den crontab-Eintrag, um das Skriptintervall zu erhöhen (damit Ihr hängendes Skript nicht viele Male ausgeführt wird).
Zeichnen Sie die Ausgabe von top für ein Intervall auf
Durchlaufen Sie den Prozessbaum in den oberen Protokollen und suchen Sie den Prozess, an dem er hängt
Durchlaufen Sie dann die Codeform, in der dasselbe aufgerufen wird.

— Shubham
quelle