Pourquoi systemd-udev arrache-t-il mon processeur?

J'ai remarqué que l'un des cœurs d'un ordinateur portable à quatre cœurs est ancré et que la température est très élevée. J'ai trouvé cela dans top:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  359 root      20   0  188684 147228   1552 R  99.4  5.0 111:19.91 systemd-udevd
20011 root      20   0  188320 147604   2076 S  11.0  5.0   0:00.33 systemd-udevd
11053 dotanco+  20   0 3030036 918672  49608 S   9.6 31.2 280:40.65 firefox
 3468 dotanco+  20   0 3612776 136740  43484 S   1.7  4.6  57:02.52 plasma-desktop
20006 root      20   0       0      0      0 Z   1.0  0.0   0:00.37 systemd-udevd

Pourquoi pourrait- systemd-udevil marteler le CPU? Il s'agit d'un système Kubuntu 14.10:

$ uname -a
Linux loathe 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 14.10 \n \l

EDIT: je remarque qu'en plus du CPU arrimé, il y a un problème supplémentaire. Les périphériques USB nouvellement connectés, tels qu'un périphérique de stockage de masse USB ou un clavier, s'affichent lsusbmais sont inutilisables. Le périphérique de stockage de masse n'est pas monté automatiquement et le clavier USB ne fonctionne pas. Je n'ai pas essayé de monter manuellement la clé USB.

Selon la suggestion de Bratchley, voici l'étendue du systemd-udevprocessus avec l'ID 359.

Il semble que libmtp ait trouvé un périphérique, mais il est incapable de le déconnecter correctement et il le vérifie constamment. Cela se produit avec certains appareils et peut être désactivé en modifiant /lib/udev/rules.d/69-libmtp.rules

Recherchez quelques lignes qui ressemblent à ceci (à la fin du fichier):

# Autoprobe vendor-specific, communication and PTP devices 
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl     ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li     bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Commentez la deuxième ligne en mettant un # avant ENV, pour qu'il ressemble à ceci:

#ENV{ID_MTP.... 

Redémarrez votre ordinateur ou exécutez sudo systemctl restart systemd-udevdet profitez de vos cycles CPU gratuits :)

Utilisez udevadm monitorpour savoir quel pilote regroupe l'unité centrale de traitement.

Une autre cause:

1. Pilote nvidia installé 396
2. Redémarrez avec un écran vide
3. NVIDIA désactivé dans le BIOS

4. Le système fonctionne avec Intel, mais après plusieurs sommeil / reprise, je l'ai obtenu udevadm monitor(lignes aléatoires mais répétant tout de même indéfiniment):

   ...
   KERNEL[10072.040174] remove   /module/nvidia (module)
   UDEV  [10072.062670] add      /module/nvidia (module)
   UDEV  [10072.063617] add      /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
   UDEV  [10072.076901] remove   /module/nvidia (module)
   UDEV  [10072.109365] add      /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
   KERNEL[10072.138225] add      /module/nvidia (module)
   KERNEL[10072.139241] add      /kernel/slab/:0012288 (slab)
   KERNEL[10072.139651] remove   /kernel/slab/:0012288 (slab)
   ...
   

Je ne suis pas sûr mais je pense que cela est dû au fait que le pilote nvidia est actif mais que nvidia est désactivé dans le BIOS.

La solution proposée par eLobato n'a pas fonctionné pour moi.

Avec les mêmes sympthoms décrits, j'ai trouvé ce fil: /ubuntu/1073185/after-upgrade-from-ubuntu-16-to-18-04-systemd-udevd-uses-100-cpu

qui a résolu le problème pour moi. Je répète la solution ci-dessous pour être complet, mais tous les crédits vont à la réponse originale de brunom4ciel.

Essayez si l'arrêt et le démarrage des processus résolvent le problème sans effets secondaires indésirables:

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sleep 5

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

Si cela fonctionne, intégrez-le dans un script sous /etc/init.d/systemd-udevd-solv.shavec:

sudo vim /etc/init.d/systemd-udevd-solv.sh

et collez:

#!/bin/sh

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sleep 5

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

Modifiez ensuite l'autorisation à exécuter lors de la connexion

sudo chmod a+x /etc/init.d/systemd-udevd-solv.sh

Il y a un bogue dans le noyau qui provoque une utilisation de 100% du CPU par systemd-udevs.

Ainsi, la solution consiste à redémarrer le système, à maintenir la touche Maj enfoncée pendant le chargement de Grub. Sélectionnez ensuite l'ancien noyau répertorié dans la liste du chargeur de démarrage.

Cela fonctionne bien pour moi.

J'ai eu le même problème sur Linux Mint 17.3 Rosa.

Pour le résoudre, lorsque mon PC est inactif:

• J'ouvre le terminal.
• Connectez-vous en tant que SU.
• Utilisez la topcommande et voyez le PID de systemd.
• Tue le.

Le CPU est revenu à la normale et l'utilisation de la RAM est devenue faible. Bien sûr, mon bureau est toujours stable. Je peux utiliser mon bureau normalement après cette opération.

J'ai trouvé que c'était un problème sur certaines installations de CentOS fonctionnant sur Hyper-V . La désactivation d'Integration Services dans les paramètres de la machine virtuelle semble l'avoir résolu. Plus précisément la synchronisation de l'heure .