Welcher Prozess schreibt auf welche Datei?
Bernd Hohmann
welche Datei schreibt.
"iotop -boP" liefert mir brav die Prozesse, die gerade IO machen - aber
ich brauch auch die Info, wo die IO machen.
Konkret geht es um eine Thirdparty Applikation die recht grosszügig ihre
Logfiles verteilt und keiner weiss wohin genau.
Bernd
--
Life was much easier when Apple and Blackberry were just fruits.
Frank Ursel
> Ich brauch eigentlich "nur" eine fortlaufende Liste welcher Prozess auf
> welche Datei schreibt.
man lsof
Bernd Hohmann
>> Ich brauch eigentlich "nur" eine fortlaufende Liste welcher Prozess auf
>> welche Datei schreibt.
>
> lsof ?
Kluge Idee - nur welcher der vielen Parameter und deren Kombinationen
fischt kontinuierlich die schreibenden Prozesse mit ihren Dateien heraus?
Nach 'ner halbe Stunde Irrungen und Wirrungen habe ich jedenfalls
nichtmal ansatzweise was brauchbares herauslocken können.
Offene Dateien interessieren mich nicht, wer daraus liest auch nicht -
aber schon wer dort auch mal irgendwann reinschreibt. Und dann halt auch
dass viele Prozesse eine Datei mal eben kurz aufmachen, lesen, zumachen
(die brauch ich nicht) aber dafür die Prozesse, die eine Datei
aufmachen, schreiben, zumachen.
Dh unter Umständen ein 24h Monitoring.
Marcel Müller
> Dh unter Umständen ein 24h Monitoring.
24 Std trace file, ohne zu wissen, welches Programm man haben will?
Das halte ich für illusorisch.
Was soll das denn werden? Übeltäter suchen? SSD-Optimierung?
Bei letzterem sollte man sich darüber im Klaren sein, dass bei weitem
nicht jeder Schreibbefehl von einer Anwendung auf einem Storage-Device
landet. Bei mir am Desktop ist es beispielsweise nur etwa jeder zehnte.
Wenn es wirklich die harte Tour werden soll und auch noch einigermaßen
performant, würde ich versuchen, den Kernel zu patchen.
Marcel
Harald Meyer
> (die brauch ich nicht) aber dafür die Prozesse, die eine Datei
> aufmachen, schreiben, zumachen.
Die Brutal-Methode wäre mit strace sämtliche Systemaufrufe loggen,
da siehst du wann der Prozess wo was schreibt.
Ralph Angenendt
Aber dafür braucht er den Prozess. Ich muss ganz ehrlich sagen, dass ich
die Fragestellung nicht ganz verstehe:
Ist der Prozess (und seine Kinder) bekannt? Ist grob bekannt, wo
hingeschrieben wird? Geht es darum, rauszufinden, wo Platz verbraten
wird? Oder müssen die anfallenden Dateien weiterverarbeitet werden?
Ralph
--
E.E. CUMMINGS BELIEVES IN CAPSLOCK
-- @amandapalmer
Nicht schreiben können: http://lestighaniker.de/
Bernd Hohmann
> Was soll das denn werden? Übeltäter suchen? SSD-Optimierung?
Lediglich alle periodischen Schreibzugriffe herausfinden und auf ein
entsprechendes Medium umleiten.
Eigentlich eine 08/15 Frage, verstehe nicht warum darauf so agressiv
reagiert wird.
Und ja: es geht um eine Optimierung - nämlich eine Aufteilung von
Grundsystem, Protokoll und Bewegungsdaten vorzunehmen.
Harald Meyer
>> Die Brutal-Methode wäre mit strace sämtliche Systemaufrufe loggen,
>> da siehst du wann der Prozess wo was schreibt.
>
> Aber dafür braucht er den Prozess. Ich muss ganz ehrlich sagen, dass ich
> die Fragestellung nicht ganz verstehe:
>
> Ist der Prozess (und seine Kinder) bekannt?
In der Frage hiess es doch "Konkret geht es um eine Thirdparty Applikation",
also muss er doch wohl wissen wie das Ding heisst.
Ralph Angenendt
> Lediglich alle periodischen Schreibzugriffe herausfinden und auf ein
> entsprechendes Medium umleiten.
Also einer bekannten Applikation von der du weißt, welche Prozesse sie
startet? strace -ff -eopen - das zeigt zumindest welche Dateien geöffnet
werden. Du kannst natülich auch in /proc/$pid/fd/ nach den
Dateideskriptoren gucken (aber wahrscheinlich kein inotify darauf
ansetzen).
> Eigentlich eine 08/15 Frage, verstehe nicht warum darauf so agressiv
> reagiert wird.
Ich sehe nicht, dass hier aggressiv reagiert wurde, man versucht
lediglich von dir eine etwas genauere Beschreibung des Problems zu
erlangen.
Cheers,
Bernd Hohmann
>> Lediglich alle periodischen Schreibzugriffe herausfinden und auf ein
>> entsprechendes Medium umleiten.
>
> Also einer bekannten Applikation von der du weißt, welche Prozesse sie
> startet? strace -ff -eopen - das zeigt zumindest welche Dateien geöffnet
> werden.
strace ist eine Idee, muss ich entsprechend filtern gehen.
> Du kannst natülich auch in /proc/$pid/fd/ nach den
> Dateideskriptoren gucken (aber wahrscheinlich kein inotify darauf
> ansetzen).
Hm, warum nicht? Etwas brutal aber der Ansatz mit inotify gefällt mir.
Bernd Hohmann
> Ralph Angenendt wrote:
>> Du kannst natülich auch in /proc/$pid/fd/ nach den
>> Dateideskriptoren gucken (aber wahrscheinlich kein inotify darauf
>> ansetzen).
>
> Hm, warum nicht? Etwas brutal aber der Ansatz mit inotify gefällt mir.
Funzt prächtig...
inotifywait --exclude /dev -rme
modify,attrib,move,close_write,create,delete,delete_self /
Wenn ich jetzt mein Regex-Handbuch finde um für "--exclude" ein "/dev OR
/srv" zu schreiben ist der Käse in meinem Fall gegessen.
Ralph Angenendt
>> Dateideskriptoren gucken (aber wahrscheinlich kein inotify darauf
>> ansetzen).
>
> Hm, warum nicht? Etwas brutal aber der Ansatz mit inotify gefällt mir.
Weil ich nicht weiß, ob du inotify auf /proc ansetzen kannst.
Bernd Hohmann
>> > Du kannst natülich auch in /proc/$pid/fd/ nach den
>>> Dateideskriptoren gucken (aber wahrscheinlich kein inotify darauf
>>> ansetzen).
>>
>> Hm, warum nicht? Etwas brutal aber der Ansatz mit inotify gefällt mir.
>
> Weil ich nicht weiß, ob du inotify auf /proc ansetzen kannst.
Nein - aber Rekursiv von / herab auf alle Dateien.
Hauke Laging
> Die Brutal-Methode wäre mit strace sämtliche Systemaufrufe loggen,
> da siehst du wann der Prozess wo was schreibt.
Das wäre nicht nur brutal, sondern auch dumm. :-)
strace -p $PID -f -e trace=file
Womöglich reicht trace=open.
CU
Hauke Laging
> Wenn ich jetzt mein Regex-Handbuch finde um für "--exclude" ein "/dev OR
> /srv" zu schreiben ist der Käse in meinem Fall gegessen.
So was wie '/(dev|srv)'?
--
http://www.hauke-laging.de/ideen/
Bernd Hohmann
>> Wenn ich jetzt mein Regex-Handbuch finde um für "--exclude" ein "/dev OR
>> /srv" zu schreiben ist der Käse in meinem Fall gegessen.
>
> So was wie '/(dev|srv)'?
Ah, genau - das ' fehlte mir drumherum.
Du hast einen einfachen Entwickler sehr glücklich gemacht.
Hauke Laging
> Ich brauch eigentlich "nur" eine fortlaufende Liste welcher Prozess auf
> welche Datei schreibt.
Ein Alternativvorschlag zu inotify, das ja, wenn ich das richtig sehe, keine
Information über den jeweiligen Prozess liefert.
Mit auditctl kann man sich entsprechende Regeln basteln, die nur eine PID
betreffen. Ich habe es nicht getestet, vermute aber, dass das performanter
ist als strace.
Und wenn man es nicht auf eine PID begrenzt, kann man sich die
Gesamtübersicht des Systems holen: Welcher Prozess schreibt in welche Datei?
Bernd Hohmann
>> Ich brauch eigentlich "nur" eine fortlaufende Liste welcher Prozess auf
>> welche Datei schreibt.
>
> Ein Alternativvorschlag zu inotify, das ja, wenn ich das richtig sehe, keine
> Information über den jeweiligen Prozess liefert.
Das ist richtig. Aber aus der Info von "inotifywait" findet man den
Verursacher schnell:
/var/lib/ntp/ CREATE ntp.drift.TEMP
/var/lib/ntp/ MODIFY ntp.drift.TEMP
/var/lib/ntp/ CLOSE_WRITE,CLOSE ntp.drift.TEMP
/var/lib/ntp/ MOVED_FROM ntp.drift.TEMP
/var/lib/ntp/ MOVED_TO ntp.drift
Ok, nix für einen Lastesel oder gar für kompromittierte Systeme - aber
schonmal eine Eingrenzung.
> Mit auditctl kann man sich entsprechende Regeln basteln, die nur eine PID
> betreffen.
Ich hab ähnliches in apparmor gefunden, aber alles viel kompliziert.
> Und wenn man es nicht auf eine PID begrenzt, kann man sich die
> Gesamtübersicht des Systems holen: Welcher Prozess schreibt in welche Datei?
Nachdem was ich so gefunden habe: ausser hooks via inotifywait gibt es
da nix.
Juergen Ilse
Bernd Hohmann <bernd.hohma...@freihaendler.com> wrote:
> Martin Schnitkemper wrote:
>>> Ich brauch eigentlich "nur" eine fortlaufende Liste welcher Prozess auf
>>> welche Datei schreibt.
>> lsof ?
> Kluge Idee - nur welcher der vielen Parameter und deren Kombinationen
> fischt kontinuierlich die schreibenden Prozesse mit ihren Dateien heraus?
Waere es nicht sinnvoller, mittels strave die Systemaufrufe zu protokol-
lieren und daraus dann dir Aufrufe herauszufischen, die Dateieb zum schrei-
ben offnen? Das waere zumindest meine erste Idee gewesen ...
> Offene Dateien interessieren mich nicht, wer daraus liest auch nicht -
> aber schon wer dort auch mal irgendwann reinschreibt. Und dann halt auch
> dass viele Prozesse eine Datei mal eben kurz aufmachen, lesen, zumachen
> (die brauch ich nicht) aber dafür die Prozesse, die eine Datei
> aufmachen, schreiben, zumachen.
Das klingt doch eher danach, die Aufrufe eine Datei zum schreiben zu
oeffnen mitzuprotokollieren ...
> Dh unter Umständen ein 24h Monitoring.
Da kommen dann u.U. sehr viele Daten zusammeb. Trotzdem wuerde ich es
erst einmal mit einem solchen Ansatz versuchen ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...