debianforum.de

Hallo,

immer wieder rattert minutenlang meine HDD, obwohl ich nichts mache. Manchmal finde ich die Ursache nicht (kein cronjob (logrotate o.ä.); Browser oder Emailclient mit Datenbank komprimierung, usw.). Ich suche ein tool ähnlich 'top', dass mir in Echtzeit Dateizugriffe anzeigt. Gibt es so etwas? Mit lsof kriege ich ja eine unendlich lange Momentaufnahme. Mich interessiert aber welcher Prozess gerade viele Neuzugriffe durchführt.

Danke im Voraus

Danke! War mal wieder zu blöd es selber zu finden

Nachtrag: Jetzt muss ich doch noch mal eine DAU-Frage stellen: Wie halte ich die Aktualisierung von iotop an? Gibt es dafür keinen Hotkey (Hold-Funktion?)? Bei top nutze ich 'd'. Dann kann ich das Aktualisierungsintervall ändern. Solang die Eingabezeile da ist, steht die aktuelle top-Anzeige. Insofern habe ich bei top auch noch keine richtige Hold-Funktion gefunden. Bei iotop gibt es wohl keinen d-hotkey

iotop ist zwar ein klasse tool für meinen Zweck (Prozess finden, der hohe Lesezugriffe erzeugt), aber nicht ganz das, was ich erhofft habe: Die Dateien, auf der jeweilige Prozess zugreift, sehe ich so ja nicht. Die muss ich dann wieder mit 'lsof -p PID' abfragen. Gibt es für soetwas vielleicht auch ein tool? Oder alternativ: Kann man lsof so ausführen, dass es ewig läuft und jeden neuen Dateizugriff direkt ausgibt?

Prinzipiell werden dafür keinerlei Zusatz-Programme benötigt. Dafür kann man das Kernel-I/O-Logging aktivieren.

Damit wird es mit Rootrechten aktiviert: Standardmäßig ist es allerdings auf 0, und sollte nach der Suche wieder umgestellt werden. Ansonsten werden die Logs sehr schnell überlaufen, die gleichermaßen nach /var/log/debug und /var/log/syslog geschrieben werden.

Im Anschluss kannst die I/O-Aktivität folgendermaßen verfolgen: Damit kannst stets die I/O-Aktivität sehen bzw. die Lese -und Schreibvorgänge, die ab diesem Zeitpunkt stattfinden samt verantwortlichem Prozess. Alternativ kann man auch journalctl verwenden, wenn einem das lieber ist.

Kermit24 hat geschrieben:Die Dateien, auf der jeweilige Prozess zugreift, sehe ich so ja nicht. Die muss ich dann wieder mit 'lsof -p PID' abfragen.

Ich würde lsof gar nicht verwenden, noch ist es ein Teil der Standard-GNU-Programme. Und persönlich finde Ich es wenig hilfreich und sehr ineffizient, wenn man wirklich Informationen gewinnen will.

Und sofern den entsprechenden Prozess identifiziert hast, kannst Dich mittels strace -o LOG -p PID einklinken, und im Detail sehen was dieser Prozess genau tut. Damit kriegst in jedem Fall raus was hier passiert.

breakthewall hat geschrieben:Prinzipiell werden dafür keinerlei Zusatz-Programme benötigt. Dafür kann man das Kernel-I/O-Logging aktivieren.

Damit wird es mit Rootrechten aktiviert:

Code: Alles auswählen

echo "1" > /proc/sys/vm/block_dump

Danke, wäre eine super Lösung, wenn ich eben meine Logfiles damit nicht versauen würde
Kann man die I/O Ausgaben nicht auch irgendwie in ein extra log-file umleiten?

journald erzeugt wohl immer nur ein Sammellog ala syslog / messages
(abgesehen von der Auftrennung für die jeweiligen Benutzer),
nur die Darstellung kann gefiltert werden.

rsyslog hat solche Filtermechanismen.
-> journal-Dateien ins Nirwana schicken und die Aufgabe durch den nachgeschalteten rsyslog erledigen.

Ob das einfach durch Abschaltung+Deaktivierung des systemd-journald.service funktioniert?
Könnte sein, daß rsyslog dann kein Input bekommt.
----------------------------------
EDIT, nach stop des systemd-journald.service (zwangsweise auch seine sockets)
empfängt rsyslog keine Meldungen mehr!

Bei der Suche nach einem anderen Problem bin ich auf auditd gestoßen,
vielleicht wäre auditctl daraus was für dich, schreibt seine logs nach /var/log/audit
zB:
https://unix.stackexchange.com/question ... ing-a-file