Ma situation est que de temps en temps un processus spécifique (dans ce cas, c'est Thunderbird) ne réagit pas aux entrées des utilisateurs pendant une minute environ. J'ai découvert iotop
que pendant ce temps, il écrit beaucoup sur le disque, et maintenant je veux savoir dans quel fichier il écrit, mais iotop
ne donne malheureusement que des statistiques par processus et non par fichier ouvert (-descriptor).
Je sais que je peux utiliser lsof
pour savoir quels fichiers le processus a actuellement ouverts, mais bien sûr Thunderbird en a beaucoup ouverts, donc ce n'est pas très utile. iostat
affiche uniquement les statistiques par appareil.
Le problème se produit uniquement de manière aléatoire et cela peut prendre un certain temps avant qu'il n'apparaisse, donc j'espère que je n'aurai pas à parcourir Thunderbird et à parcourir de longs journaux pour savoir quel fichier contient le plus d'écritures.
la source
Réponses:
Si vous attachez strace au processus juste au moment où il est bloqué (vous pouvez obtenir le pid et mettre la commande en file d'attente à l'avance, dans un terminal de rechange), il affichera le descripteur de fichier de l'écriture bloquante.
Exemple trivial:
la source
lsof -p $PID
, afin de savoir où pointe le descripteur de fichierls -l /proc/pid/fd
sur LinuxSi vous avez un accès root, je pense que le meilleur outil serait le sous-système d'audit . Il n'y a pas beaucoup de littérature à ce sujet (mais plus que sur logsfs); vous pouvez commencer avec ce tutoriel ou un quelques exemples ou tout simplement la
auditctl
page de manuel . Ici, il devrait suffire de s'assurer que le démon est démarré, puis exécuté enauditctl
tant que root:Cela écrit dans les journaux
/var/log/audit/audit.log
chaque fois que le processus avec le pid 1234 écrit quelque part sous/home/philipp
. Les frais généraux sont assez petits, beaucoup plus petits questrace
.la source
-S read -S write
(non testé).