Cela fait environ un mois, très exactement depuis que j'ai basculé sur la cooker pour tester en avance de phase Mandriva 2009.0, que je me retrouve sous Eclipse avec un bug des plus étonnant. Le symptôme est aussi simple qu'agaçant, chaque ouverture de fichier prend en gros 2 secondes... J'ai attendu patiemment la 2009.0 pour voir si le problème serait corrigé, mais rien à faire. Je me suis alors enfin décidé à chercher comme un grand et j'ai enfin mis la doigt sur le problème. Tout est la faute... de l'imprimante...

Premier round, le CPU...

J'ai d'abord cru à un CPU emballé mais oprofiler ne m'a pas donné raison. Aucun processus ne semble particulièrement occuper le CPU, ce qui est confirmé par un bête ntop.

Noter au passage que pour utiliser oprofiler de manière optimum, ce dernier a besoin de votre noyau sous sa forme non-compressée (vmlinux et non pas vmlinuz). Ne cherchez pas un moyen de décompresser votre /boot/vmlinuz en l'autre, cela n'existe pas. En fait vmlinuz est un peu comme ces exécutables compressés, une première partie contient le code du décompresseur et la seconde les données. la seul solution est d'aller dans les sources du kernel et de lancer un simple make vmlinux. Le fichier est alors compilé dans le dossier arch/x86.

Second round, latence...

La seconde possibilité est une latence, ou un timeout. Du coup je me lance sur un strace eclipse 2> logs pour afficher en temps réels les appels systèmes effectués par Eclipse. Dans une autre console je lance un tail -f log. Vu le volume d'informations, je suis rapidement passé à quelque chose de la forme tail -f /home/yoran/t | grep -v timeofday | grep -v poll | grep -v "read(3" | grep -v select | grep -v writev | grep -v futex. Du coup, beaucoup moins d'informations. J'ouvre alors un fichier et je regarde ce qui se passe.

Dans les traces, je vois clairement que le coco cherche à se connecter au réseau, bizarre pour une simple ouverture de fichier. Il établit une connexion avec mon serveur et échange des informations.

Du coup, j'arrêtes strace et je lance wireshark.

Troisième round, le réseau...

WireShark est un indispensable outil de monitoring réseau, il permet ainsi de capturer toutes les informations qui circulent. Il vaut mieux du coup fermer les applications "communicantes", histoire de ne pas être paumé dans un flot de données. Ceci fait, lancement d'Eclipse et observant lors de l'ouverture de ce maudit fichier...

Là c'est confirmé, une connexion est bien ouverte sur le serveur, suivi d'une série de transaction, sur le port 631, c'est à dire celui de... cups...

Quatrième round, pourquoi CUPS ?!?

Un peu surpris tout de même... Pour information, notre imprimante est déportée prés du serveur dans une autre pièce et nous imprimons donc via le réseau. Il y a un donc bien un service CUPS sur le serveur et juste les librairies en local.

Nouvelle observation des traces un peu avant la fameuse connexion au serveur, et là je me rend compte que lors de cette fameuse ouverture de fichier, Eclipse (ou une librairie partagée) va lire le fichier de configuration cups (/etc/cups/client.conf). Il y trouve mon serveur distante et va lui causer... Incompréhensible... Notez que j'ai refais le même test avec un utilisateur bidon, sur un compte totalement vierge, avec un eclipse tout frais sur une JVM SUN, rien n'y a fait, même résultat...

La solution la plus bidon au monde...

J'ai tout essayé et le seule moyen que j'ai trouvé est de déplacer /etc/cups, lancer eclipse, et remettre le dossier cups à sa place. De toute beauté...

Conclusion

Ce problème et sa solution ne va sûrement pas toucher grand monde, mais peut-être que la "démarche" peut intéresser ceux qui se trouvent face à cette famille de bug systémiques et vicieux. Le genre de bugs qui laisse google sans voix, jusqu'au moment où l'on a la solution et qu'on lui demande eclipse cups... No comments, ça me rappelle le codage de la bible cette histoire...

Commentaires