[gelöst] ungewöhnlicher Vorfall bei iftop

[debianuser4782]

iftop läuft bei mir als root im Terminal. Kürzlich "krallte" sich das Programm eines meiner 8 Threads. In htop konnte ich sehen, dass dieser Thread permanent bei 100 % lag. Zudem wurde der Lüfter meines Laptops lauter. Von Zeit zu Zeit krallte sich iftop einen anderen Thread und dasselbe Spiel ging weiter. In der Terminal-Ansicht von iftop erschienen zudem seltsame Grafiken und Pixel, vermutlich erstellt durch ncurses. Ich veruchte den Prozess iftop über den Befehl "kill iftop" zu beenden, was aber nicht funktionierte. Auch das abwürgen über htop gelang nicht. Erst nach dem Befehl "kill [PID von iftop]" im root-Terminal, wurde der Prozess beendet.
Kann man auf Grundlage meiner Schilderungen bereits vermuten, wo das Problem lag?
Und wo könnte ich für die Zukunft Logs oder sonstige Aufzeichnungen finden, die das Problem feiner auflösen? Eine verbose-Funktion besitzt iftop nicht.

[TRex]

eines meiner 8 Threads

Du meinst einen deiner CPU-Kerne.

Ich veruchte den Prozess iftop über den Befehl "kill iftop" zu beenden, was aber nicht funktionierte.

Versuchs härter. kill ohne weitere verwendet SIGTERM, also bittet den Prozess, sich zu beenden. Das funktioniert nur, wenn der Prozess auch reaktionsfähig ist, und die Routinen für die Beendigung durchlaufen (das kann sowas sein wie ein Dialog, ob du dein Dokument speichern möchtest oder sowas).

Kann man auf Grundlage meiner Schilderungen bereits vermuten, wo das Problem lag?

Leider nicht. Vielleicht irgendeine Veränderung am Netzwerkdevice, was iftop nicht vertragen hat.

Und wo könnte ich für die Zukunft Logs oder sonstige Aufzeichnungen finden, die das Problem feiner auflösen? Eine verbose-Funktion besitzt iftop nicht.

strace und ltrace können kernel- und library calls eines laufenden Programms anzeigen. Ist aber ziemlich verbose - ich empfehle, das an einem sehr kleinen Programm anzuschauen (strace cat /etc/hosts beispielsweise), um ein Gefühl zu bekommen, was das tut.

[debianuser4782]

eines meiner 8 Threads

Du meinst einen deiner CPU-Kerne.

Ich meine eines der 8 Threads von dem bei mir laufenden Intel Core i7-6700HQ mit 4 Kernen. Ich beziehe mich auf die bei htop ganz oben aufgelisteten Threads.

Ich veruchte den Prozess iftop über den Befehl "kill iftop" zu beenden, was aber nicht funktionierte.

Versuchs härter. kill ohne weitere verwendet TERM, also bittet den Prozess, sich zu beenden. Das funktioniert nur, wenn der Prozess auch reaktionsfähig ist, und die Routinen für die Beendigung durchlaufen (das kann sowas sein wie ein Dialog, ob du dein Dokument speichern möchtest oder sowas).

Ok ich schaue mir mal die Optionen des Befehls "kill" näher an.
Die PID-Nummer eines Prozesses zu verwenden ist ok oder sollte man sowas vermeiden. Ich hatte diese Methode damals schnell per Suchmaschine gefunden.

Kann man auf Grundlage meiner Schilderungen bereits vermuten, wo das Problem lag?

Leider nicht. Vielleicht irgendeine Veränderung am Netzwerkdevice, was iftop nicht vertragen hat.

Das könnte es gewesen sein! Es liegt zwar schon etwas zurück, aber ich meine damals in zeitlicher Nähe zum Vorfall firmware-realtek und firmware-misc-nonfree installiert zu haben.

Und wo könnte ich für die Zukunft Logs oder sonstige Aufzeichnungen finden, die das Problem feiner auflösen? Eine verbose-Funktion besitzt iftop nicht.

strace und ltrace können kernel- und library calls eines laufenden Programms anzeigen. Ist aber ziemlich verbose - ich empfehle, das an einem sehr kleinen Programm anzuschauen (strace cat /etc/hosts beispielsweise), um ein Gefühl zu bekommen, was das tut.

Vielen Dank, ich schaue mir das genauer an.

[Livingston]

Ok ich schaue mir mal die Optionen des Befehls "kill" näher an.
Die PID-Nummer eines Prozesses zu verwenden ist ok oder sollte man sowas vermeiden. Ich hatte diese Methode damals schnell per Suchmaschine gefunden.

Ohne PID geht's gar nicht. Wenn Du einen Prozess mit Namen stoppen willst, brauchst Du killall. Aber Vorsicht: Wie der Name schon sagt, stoppst Du alle Prozesse dieses Namens. killall bash schließt z.B. zuverlässig alle offenen Terminals und logt Dich aus den virtuellen Konsolen aus.

kill kann verschiedene Signale an einen bestimmten Prozess senden. Standard ist SIGTERM, was den Prozess höflich bittet, sich zu beenden. Wenn ein Prozess überhaupt nicht mehr will, und auch auf SIGTERM nicht reagiert, hilft auch ein beherztes kill -SIGKILL <Prozessnummer> oder gleichbedeutend kill -9 <Prozessnummer>. Das ist dann his masters voice, der Prozess begeht sofort Selbsmord, reißt aber eventuell alles mit sich in den Abgrund, was an ihm dranhängt: Offene Dateien werden nicht sauber geschlossen, abhängige Prozesse versterben mit, usw. Also wirklich nur benutzen, wenn man weiß, was man damit anrichtet.

[debianuser4782]

Ok ich schaue mir mal die Optionen des Befehls "kill" näher an.
Die PID-Nummer eines Prozesses zu verwenden ist ok oder sollte man sowas vermeiden. Ich hatte diese Methode damals schnell per Suchmaschine gefunden.

Ohne PID geht's gar nicht. Wenn Du einen Prozess mit Namen stoppen willst, brauchst Du killall. Aber Vorsicht: Wie der Name schon sagt, stoppst Du alle Prozesse dieses Namens. killall bash schließt z.B. zuverlässig alle offenen Terminals und logt Dich aus den virtuellen Konsolen aus.

kill kann verschiedene Signale an einen bestimmten Prozess senden. Standard ist SIGTERM, was den Prozess höflich bittet, sich zu beenden. Wenn ein Prozess überhaupt nicht mehr will, und auch auf SIGTERM nicht reagiert, hilft auch ein beherztes kill -SIGKILL <Prozessnummer> oder gleichbedeutend kill -9 <Prozessnummer>. Das ist dann his masters voice, der Prozess begeht sofort Selbsmord, reißt aber eventuell alles mit sich in den Abgrund, was an ihm dranhängt: Offene Dateien werden nicht sauber geschlossen, abhängige Prozesse versterben mit, usw. Also wirklich nur benutzen, wenn man weiß, was man damit anrichtet.

Genau so war es! Ich kann mich wieder erinnern. Zumindest brach für mich erkennbar meine ganze Internetverbindung zusammen und ich musste mein System neu booten. Vielen Dank! Ich schaue mir das nochmal genauer an. Ich habe diese Befehle in der Vergangenheit etwas inflationär gebraucht.