Por que o systemd-udev está atrelando minha CPU?

10

Eu notei que um dos núcleos em um laptop de quatro núcleos é indexado e a temp é muito alta. Eu encontrei isso em 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

Por que systemd-udev pode estar martelando a CPU? Este é um sistema 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

EDITAR: percebo que, além da CPU vinculada, há um problema adicional. Dispositivos USB recém-conectados, como um dispositivo de armazenamento em massa ou teclado USB, serão exibidos em lsusb , mas estarão inutilizáveis. O dispositivo de armazenamento em massa não é montado automaticamente e o teclado USB não funciona. Eu não tentei montar manualmente a unidade USB.

De acordo com a sugestão de Bratchley, aqui está o strace do processo systemd-udev com ID 359.

    
por dotancohen 01.10.2015 / 13:29

6 respostas

11

Parece que o libmtp encontrou um dispositivo, mas não consegue desconectá-lo corretamente e está verificando-o constantemente. Isso acontece com determinados dispositivos e pode ser desativado editando /lib/udev/rules.d/69-libmtp.rules

Procure algumas linhas semelhantes a esta (no final do arquivo):

# 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"

Comente a segunda linha colocando um # antes de ENV, para que pareça:

#ENV{ID_MTP.... 

Reinicie seu computador ou execute sudo systemctl restart systemd-udevd e aproveite seus ciclos de CPU gratuitos :)

    
por 19.03.2016 / 17:13
6

Use udevadm monitor para descobrir qual driver está agrupando a cpu.

    
por 07.05.2018 / 15:55
1

Outra causa:

  1. Instalado driver nvidia 396
  2. Reinicie com a tela em branco
  3. Desativado nvidia no BIOS
  4. O System funciona com a Intel, mas depois de vários sleep / resume eu obtive isso de udevadm monitor (linhas aleatórias, mas repetindo assim mesmo indefinidamente):

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

Não tenho certeza, mas espero que isso seja causado pelo fato de o driver nvidia estar ativo, mas a nvidia está desativada no BIOS.

    
por 13.06.2018 / 09:42
1

Existe um bug no kernel que faz com que o systemd-udev use 100% da CPU.

Assim, o trabalho é reinicializar o sistema, pressione e segure a tecla Shift durante o carregamento do Grub. Em seguida, selecione o kernel mais antigo listado na lista do gerenciador de inicialização.

Esse trabalho é bom para mim.

    
por 25.08.2018 / 21:21
0

Eu tive o mesmo problema no Linux Mint 17.3 Rosa.

Para resolvê-lo, quando meu PC estiver inativo:

  • eu abro o terminal.
  • Faça login como SU.
  • Use o comando top e veja o PID de systemd .
  • Mate-o.

A CPU voltou ao normal e o uso da RAM foi baixo. Claro que meu desktop ainda está estável. Posso usar minha área de trabalho normalmente depois dessa operação.

    
por 27.09.2016 / 23:50
0

Eu descobri que isso é um problema em algumas instalações do CentOS rodando no Hyper-V . Desativar o Integration Services nas configurações da VM parece tê-lo resolvido. Especificamente Sincronização de horário .

    
por 02.11.2017 / 17:57