Nous avons récemment rencontre un problème curieux sur notre installation ITIM / ITDI : le processus ITDI IDIloader.jar est en permanence à 100% de CPU sur le serveur, alors même qu'il ne traite aucune donnée.
Les logs ne donnent pas d'informations.
Symptômes
La commande top donne le résultat suivant :
top - 10:57:29 up 115 days, 2:00, 4 users, load average: 1.03, 1.08, 0.83
Tasks: 200 total, 1 running, 198 sleeping, 0 stopped, 1 zombie
Cpu(s): 76.4%us, 23.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3925320k total, 3774292k used, 151028k free, 6860k buffers
Swap: 4194296k total, 2721804k used, 1472492k free, 530284k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21871 itdi 20 0 1213m 145m 7104 S 99.9 3.8 10:51.67 java
1 root 20 0 19216 688 508 S 0.0 0.0 0:13.72 init
On identifie le processus fautif :
ps -ef | grep 21871 itdi 21871 21862 88 10:46 ? 00:13:40 /product/itdi/TDI-71/jvm/jre/bin/java -cp /product/itdi/TDI-71/IDILoader.jar -Dlog4j.configuration=file:etc/log4j.properties com.ibm.di.loader.ServerLauncher -s /product/itdi/TDI-71/timsol -c ITIM_RMI.xml -d
Aucun fichier de log ne donne de piste probante. L'utilisation de la commande lsof ne montre qu'un seul fichier en écriture, le fichier ibmdi.log, qui ne donne pas plus d'informations.
Identification du problème
Un collègue / expert unix envoie alors un kill -QUIT sur le processus, ce qui provoque un thread dump sur le process Java, et permet d'analyser les causes du problème.
Il identifie que l'un des threads java est en attente de ressource sur un fichier dans le répertoire /tmp, et qu'il ne possède pas les bons droits :
ls -al /tmp/ total 88 drwxrwxrwt. 8 root root 4096 7 févr. 10:46 . dr-xr-xr-x. 25 root root 4096 3 févr. 20:38 .. drwxr-xr-x 2 explitdi explitdi 4096 7 févr. 10:45 .com_ibm_tools_attach
En effet, le propriétaire du processus ITDI ne peut pas écrire dans ce répertoire.
Résolution
Les droits sont alors modifiés sur le répertoire en question :
# chmod 775 /tmp/.com_ibm_tools_attach # chgrp itdi /tmp/.com_ibm_tools_attach # ls -al /tmp total 88 drwxrwxrwt. 8 root root 4096 Feb 7 10:46 . dr-xr-xr-x. 25 root root 4096 Feb 3 20:38 .. drwxrwxr-x 2 explitdi itdi 4096 Feb 7 11:00 .com_ibm_tools_attach
Le résultat est aussitôt visible : le processus ITDI IDILoader.jar disparaît du top des process :
top
top - 11:00:37 up 115 days, 2:03, 2 users, load average: 0.74, 0.98, 0.83
Tasks: 193 total, 1 running, 191 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 0.9%sy, 0.0%ni, 91.2%id, 3.4%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 3925320k total, 3769352k used, 155968k free, 7484k buffers
Swap: 4194296k total, 2722080k used, 1472216k free, 531384k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 19216 688 508 S 0.0 0.0 0:13.72 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
Explication de notre problème
Le souci vient de l'utilisation de 2 comptes systèmes pour ITDI : le compte itdi est utilisé pour lancer le processus itdi (via la commande /etc/init.d/ITIMAd start, alors que l'utilisateur explitdi lance des lignes d'assemblage de type IDI Data Feed vers ITIM. Nous avons du tomber dans une configuration où le premier lancement a été fait avec l'utilisateur explitdi, qui s'est octroyé les droits sur le répertoire /tmp/.com_ibm_tools_attach. Lorsque le serveur ITDI a été lancé par la suite, il n'a pas pu accéder à ce répertoire, et le processus est parti en vrille...
Au fait, que contient ce répertoire ? Le fichier de PID du processus, et des fichiers utilisés comme sémaphores. Tout ceci est amené par des considérations de sécurité des Java Attach API
Référence : http://www-01.ibm.com/support/docview.wss?uid=swg21407964