Joyeusetés (ou débilités) matinales de Fedora 16
Par trashy le jeudi 8 décembre 2011, 06:56 - PenguinLand - Lien permanent
Ce matin, comme bien d'autres, je me mets sur la dos de Galette, pour résoudre quelques bogues, rédiger un brin de documentation, bref, pour bosser en somme.
Comme à l'accoutumée, je lance dans une console en root un tailf
/var/log/http/error_log ; et un tailf logs/galette.log
dans une autre, en user. Jusque là, rien de bien excitant me direz-vous, et
vous aurez raison. Oui, mais ce matin... Le second tailf échoue ; avec un
message laconique :
% tailf logs/galette.log tailf: logs/galette.log : impossible d'ajouter une surveillance inotify (la limite de surveillances inotify a été atteinte).
Chouette. La sortie de tail -f ne diffère qu'à peine :
% tail -f logs/galette.log tail: inotify resources exhausted tail: inotify ne peut pas être utilisé, retour à l'interrogation active
Bon, OK, c'est pas un bon matin. Première vérification : l'espace
disque disponible. Tout est correct de ce côté là ; c'est pas ça 
Après quelques recherches, je trouve la commande qui me permet de lister, par ordre de gourmandise, les processus qui consomment le plus de ce côté. Lançons nous :
% for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr
1 /proc/2655/fd/anon_inode:inotify
1 /proc/2622/fd/anon_inode:inotify
1 /proc/2609/fd/anon_inode:inotify
1 /proc/2511/fd/anon_inode:inotify
1 /proc/2503/fd/anon_inode:inotify
Et voici donc les coupables :
goa-daemon(process 2655) - qui remporte la palme toutes catégories confonduestracker-miner-flickr(process 2622)nautilus -n(process 2609)tracker-store(process 2511)tracker-miner-fs(process 2503)
Mis à part nautilus (bien que je me demande toujours pourquoi
nautilus prend un malin plaisir à se charger de l'afficage de mon bureau
XFCE ; mais passons ce point de détail) ; je n'ai recours à aucun des
services proposés, mieux même : je n'en veux pas. Tracker (à ce que j'en
sais) indexe les données présentes (je ne sais top ou d'ailleurs) pour
effectuer des recherches. Chouette ; je suis super content, j'utilise
uniquement la console pour effectuer des recherches quand j'en ai besoin.
J'avais déjà remarqué que certains processus tracker se
lançaient pour consommer du CPU à ne plus savoir qu'en faire (ralentissant par
ailleurs les machines les plus lentes) ; et comme ce n'était pas trop
problématique, je les avais simplement killés. Oui mais là ; ça commence à
faire beaucoup ; et je voudrai les désactiver.
Hé bien, il n'y a pas de façon simple. Supprimer tracker va virer Brasero, que je souhaiterai continuer à utiliser. La solution pour désactiver tracker, je l'ai trouvée dans un rapport de bogue au titre évocateur « provide a method to disable tracker ». Il faut créer les trois fichiers suivants :
~/.config/autostart/tracker-miner-flickr.desktop ~/.config/autostart/tracker-miner-fs.desktop ~/.config/autostart/tracker-store.desktop
Avec le contenu :
[Desktop Entry] Hidden=true
Une solution à répéter pour chaque utilisateur du système. Révolutionnaire, vraiment. Il semblerait par ailleurs que cette méthode ne soit pas la plus adaptée pour gnome-shell (voir le commentaire #2 du rapport de bogue) ; mais je me suis arrêté là, j'utilise XFCE.
Quant au démon GOA (Gnome Online Accounts), je l'ai juste killé pour le moment, je n'ai pas plus de temps à perdre ce matin pour désactiver ce que je n'ai pas demandé, qui se lance quand même, et me bouffe mes ressources...
Hope that could help.
Commentaires
> j'utilise uniquement la console pour effectuer des recherches quand j'en ai besoin
Tracker peut aussi s'utiliser en ligne de commande avec tracker-search (ça peut être pratique pour chercher dans le contenu des fichiers, mais c'est vrai qu'il bouffe beaucoup de ressources).
Pour les fichiers dans ~/.config/autostart il y a des équivalents dans /etc/xdg/autostart pour effectuer le changement sur tous les utilisateurs du système (et nautilus se désactive aussi par là).
Et augmenter les valeurs max de ces paramètres ?
Probablement parmi:
++
@Zenko : bon savoir pour le faire côté système, merci
Quant à l'utilisation de tracker en ligne de commande, @@grep@@ me suffit amplement (et me satisfait pleinement) ; je n'ai pas besoin d'autre chose, à plus forte raison si ça consomme :p
@RemiFedora : oui, j'avais vu la possibilité de monter les limites ; mais ça me semblait tout de même étrange d'avoir ce genre de problèmes... Je préfère me limiter à virer ce que je n'utilise pas dans un premier temps, quitte à remonter la limite si j'ai de nouveau le souci un jour ou l'autre