Wie sammelt man alle Dateien, die von der Linux-Anwendung geöffnet werden?

898
Sergey

Ich möchte eine Liste aller Dateien sammeln, die von einer Anwendung geöffnet werden (in meinem Fall als / w-Bulder).

'strace -f' schlägt fehl, weil er fortlaufende Öffnungen aus verschiedenen Gabeln mischt, zum Beispiel:

13078 open("file1", O_RDONLY <unfinished ...> 13077 open("file2", O_RDONLY|O_LARGEFILE) = 3 13078 <... open resumed> ) = 3

und ich kann nicht nachverfolgen, ob die "Datei1" tatsächlich geöffnet ist oder mit E_NOENT fehlgeschlagen ist.

'strace -ff' schlägt ebenfalls fehl, da zu viele Dateien erstellt werden (Anwendung macht eine sehr große Anzahl von Unterprozessen), und es erstellt das Programm. $, das Programm. $ und so weiter ein after ca. 32k forks erstellt und schreibt das Programm erneut. $, program. $ . Ich kann googeln, um die Prozessnummerierung zu erhöhen, aber trotzdem möchte ich nicht, dass es so viele Dateien gibt.

Die Frage ist also: Kann ich dieses Problem schnell und schmutzig mit strace oder einem anderen Werkzeug lösen?

2

1 Antwort auf die Frage

1
Horn OK Please

strace -f -eopen /path/to/cmd args ... 2>&1 | gzip > output.log.gz

Wenn Sie einen bestimmten Prozess und nicht alle Kinder suchen, dann:

gunzip output.log.gz | head -n500 | less

Lesen Sie die Datei, bis Sie die Prozess-ID (pid) des jeweiligen Programms finden, nach dem Sie suchen, und verwenden Sie sie grep.

Wenn Sie nach bestimmten Ergebnissen suchen (z. B. nach dem Fehlen von ENOENT), können Sie diese herausgreifen:

zgrep --invert-match ENOENT output.log.gz | less

Das geht nicht. Wie bereits erwähnt, besteht das Problem darin, dass der protokollierte Syscall (zB open ()) und sein Ergebnis (= 1 oder = -1, als ENOENT) in verschiedenen Zeilen protokolliert wird, gemischt mit anderen Syscalls open () für alle nicht vorhandenen Dateien, mit allen regulären Ausdrücken, zum Beispiel 'open. * ENOENT'. Der Festplattenspeicher reicht aus, so dass ohnehin kein Zippen erforderlich ist. Sergey vor 10 Jahren 0
Alles, was ich mit 'strace -f' und 'grep' habe, ist eine Menge nutzloser Zeichenketten, wie `open (" file1 ", O_RDONLY) Ich kann also nicht automatisch feststellen, ob es wirklich geöffnet war oder nicht, und daher kann ich nicht automatisch eine Liste aller geöffneten Dateien oder eine Liste der fehlgeschlagenen Öffnungsversuche abrufen. Das Protokoll ist sehr groß, Handarbeiten ist daher nicht akzeptabel. Sergey vor 10 Jahren 0

Verwandte Probleme