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

15

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.

systemd cpu-usage dotancohen
la source
2
Vous pourriez le stracefaire en utilisant des strace -fvvp 359chances s'il boucle continuellement sur quelque chose. Vous pourrez peut-être choisir quelque chose de significatif. C'est probablement un bogue, mais cela pourrait quand même constituer un bon rapport de bogue si vous pouvez collecter des données à ce sujet.
Bratchley
1
@Bratchley: Merci, voici le strace . Je google maintenant pour apprendre à le lire, mais tout conseil serait apprécié.
dotancohen
1
Eh bien, il ne ressemble pas à une boucle, il semble lire un tas de fichiers et modprobe-ing afin de les configurer. Juste un tas de trucs aléatoires vraiment. Est - il imprimer quoi que ce soit aux messages ou à la dmesgcommande?
Bratchley
1
J'aurais dû vérifier dmesg, je viens de réinitialiser la machine il y a environ deux ou trois heures. Merci beaucoup d'avoir confirmé qu'il n'y a pas de boucle. J'ai essayé de parcourir la strace et bien que je ne sois pas habitué à les lire, je n'ai trouvé aucune boucle infinie, ce qui est toujours la première chose à laquelle je pense lorsque les pics de CPU.
dotancohen
2
Y a-t-il quelque chose qui s'affiche lorsque vous exécutez "udevadm monitor"?
V13

Réponses:

16

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 :)

eLobato
la source
Le redémarrage était nécessaire pour moi. J'ai essayé de redémarrer systemd-udevd plusieurs fois, mais il rattacherait toujours le processeur immédiatement.
Nate Glenn
8

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

wayfactory
la source
D'ACCORD. Je pense avoir trouvé l'appareil. Et maintenant?
norok2
4

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.

dmatej
la source
1
J'ai rencontré le même problème. les pilotes Nvidia désinstallés ont résolu le problème.
TC Zhang
2

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
SeF
la source
1

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.

Yolt
la source
0

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.

Ryo Adi Suwito
la source
J'ai toujours pensé que systemd est toujours PID 1 0pointer.de/blog/projects/systemd.html
aventurin
0

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 .

Yanzzee
la source