Dans CentOS 7 ou Red Hat Enterprise Linux (RHEL) 7, un processus appelé "kipmi0" peut montrer qu'il utilise un pourcentage inhabituellement élevé de la puissance de traitement du processeur, par ex. 99,7 %, 99,8 %, 99,9 % ou même 100 %, même si le processus kipmi0 utilise 0,0 % de mémoire et n'augmente pas réellement la charge moyenne, qui continue de planer à un niveau bas proche de 1 ou 2 (à condition que le serveur ne soit pas soumis à de lourdes charger à ce moment).
Le kipmi0 problématique peut être affiché en exécutant la commande "top". Le processus kipmi0 reste à 100 % pendant toute la durée de vie du serveur.
Parfois, un redémarrage du système peut faire disparaître kipmi0 pendant un petit moment, mais il reprend bientôt vie avec une utilisation à 100% du processeur. Pour aggraver les choses, le processus kipmi0 ne peut pas être tué et terminé, où le processus continue de fonctionner et est resté.
Selon le support IBM, le processus kipmi0 peut afficher une utilisation accrue du processeur sous Linux. L'utilisation peut augmenter jusqu'à 100 % lorsque le périphérique IPMI (Intelligent Platform Management Interface), tel qu'un BMC (Baseboard Management Controller) ou IMM (Integrated Management Controller) est occupé ou ne répond pas.
La résolution suggérée est, étonnamment, ne prend aucune mesure. Aucun correctif n'est requis et l'utilisation accrue du processeur doit être ignorée car elle n'a aucun impact sur les performances réelles du système, car les threads d'assistance du noyau kipmiN sont exécutés avec une faible priorité. D'autres solutions de contournement incluent la réinitialisation du BMC ou le redémarrage du système si vous utilisez un périphérique IPMI (ce qui ne résout pas le problème), ou l'arrêt du service IPMI si vous n'utilisez pas le périphérique IPMI (où le service IPMI ne devrait même pas démarrer s'il n'est pas utilisé) .
Red Hat Enterprise Linux (RHEL)/CentOS 6 et Red Hat Enterprise Linux/CentOS 7 ont intégré les pilotes Linux IPMI ipmi_si et ses handles et modules associés dans le noyau par défaut. RedHat explique pourquoi ce kipmi0 génère une charge CPU élevée :
kipmi0 est un processus/thread d'assistance du noyau impliqué dans la gestion des interfaces IPMI. Dans IPMI, il existe plusieurs classes d'interfaces standard. Certaines de ces classes, comme KCS (Keyboard Control Style) et SMIC (System Management Interface Chip) n'utilisent pas de requêtes d'interruption (IRQ) pour signaler les changements, et nécessitent donc une interrogation pour obtenir les résultats de la commande. Les threads d'assistance du noyau kipmiN effectuent cette interrogation. Ainsi, il est normal que ces threads consomment beaucoup de temps CPU lorsqu'une opération IPMI est en cours.
Dans ce cas, il y a un problème dans l'interaction entre le pilote et le matériel/micrologiciel qui amène le pilote à croire qu'une opération est toujours en cours, entraînant la poursuite de la charge élevée du processeur jusqu'au redémarrage du système.
Pour résoudre le problème des threads d'assistance kipmiN, il existe de nombreuses solutions de contournement, telles que commenter ipmi-si et ipmisensors dans /etc/sysconfig/lm_sensors. Si vous êtes certain que le service IPMI n'est pas requis sur le serveur ou qu'aucun périphérique IPMI n'est installé sur l'ordinateur, vous pouvez désactiver le service de noyau pour IPMI.
Pour désactiver complètement le service du noyau pour IPMI, nous pouvons mettre sur liste noire les modules liés à IPMI dans l'utilitaire modprobe pour empêcher le système d'utiliser les modules du noyau IPMI. Pour ce faire, éditez le blacklist.conf dans /etc/modprobe.d/ répertoire et ajoutez la ligne suivante en tant que root :
blacklist ipmi_si blacklist ipmi_ssif blacklist ipmi_devintf blacklist ipmi_msghandler
La liste ci-dessus comprend la plupart des principaux modules IPMI démarrés au démarrage, mais tous ne sont pas démarrés par le système. Si l'un d'entre eux n'existe pas sur le système, la ligne peut être exclue.