Por que systemd-udev está vinculando minha CPU?


15

Percebi que um dos núcleos de um laptop de quatro núcleos está atrelado e a temperatura é muito alta. 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 pode systemd-udevestar 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

EDIT: Percebo que, além da CPU vinculada, há um problema adicional. Os dispositivos USB recém-conectados, como um teclado ou dispositivo de armazenamento em massa USB, serão exibidos, lsusbmas não podem ser utilizados. O dispositivo de armazenamento em massa não é montado automaticamente e o teclado USB não funciona. Não tentei montar manualmente a unidade USB.

De acordo com a sugestão de Bratchley, aqui está o rastro do systemd-udevprocesso com o ID 359.


2
Você pode straceusar as strace -fvvp 359chances de que esteja repetindo continuamente algo. Você pode escolher algo significativo. Provavelmente é um bug, mas ainda assim pode ser um bom relatório de erro se você puder coletar dados sobre ele.
Bratchley

1
@Bratchley: Obrigado, aqui está o traço . Estou pesquisando no Google agora para aprender a lê-lo, mas qualquer conselho seria apreciado.
Dotancohen

1
Bem, não parece que ele esteja em loop. Parece estar lendo um monte de arquivos e modprobe-ing para configurá-los. Apenas um monte de coisas aleatórias, na verdade. Imprime alguma coisa nas mensagens ou no dmesgcomando?
Bratchley

1
Eu deveria ter verificado dmesg, acabei de reiniciar a máquina cerca de duas ou três horas atrás. Muito obrigado por confirmar que não há loop. Tentei passar por cima do strace e, embora não seja versado em lê-los, não consegui encontrar nenhum loop infinito, que é sempre a primeira coisa que penso quando a CPU dispara.
dotancohen

2
Há algo mostrado quando você executa o "monitor udevadm"?
V13

Respostas:


16

Parece que a 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 parecidas com 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 da ENV, para que ela se pareça com:

#ENV{ID_MTP.... 

Reinicie o computador ou execute sudo systemctl restart systemd-udevde aproveite seus ciclos de CPU gratuitos :)


A reinicialização era necessária para mim. Tentei reiniciar o systemd-udevd várias vezes, mas ele sempre pegaria o processador novamente imediatamente.
Nate Glenn

8

Use udevadm monitorpara descobrir qual driver está agrupando a CPU.


ESTÁ BEM. Eu acho que encontrei o dispositivo. E agora?
Norok2 16/03/19

4

Outra causa:

  1. Driver nvidia instalado 396
  2. Reiniciar com tela em branco
  3. Nvidia desativada na BIOS
  4. O sistema funciona com a Intel, mas, após várias horas de sono / currículo, obtive isso udevadm monitor(linhas aleatórias, mas repetindo o 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 da nvidia estar ativo, mas a nvidia estar desativada no BIOS.


1
Eu tive o mesmo problema. drivers Nvidia desinstalados resolveu o problema.
TC Zhang

2

A solução proposta pelo eLobato não funcionou para mim.

Com os mesmos sintomas descritos, encontrei este tópico: /ubuntu/1073185/after-upgrade-from-ubuntu-16-to-18-04-systemd-udevd-uses-100-cpu

isso resolveu o problema para mim. Repito a solução abaixo para ser completo, mas todos os créditos vão para a resposta original de brunom4ciel.


Tente se parar e iniciar os processos resolver o problema sem efeitos colaterais indesejados:

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

Se isso funcionar, incorpore-o em um script /etc/init.d/systemd-udevd-solv.shcom:

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

e cole:

#!/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

Em seguida, altere a permissão para ser executada no login

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

1

Há um erro no kernel que causa 100% de uso da CPU systemd-udevs.

Portanto, a solução é reiniciar o sistema, pressione e mantenha pressionada a tecla Shift durante o carregamento do Grub. Em seguida, selecione o kernel mais antigo listado na lista do gerenciador de inicialização.

Este trabalho é bom para mim.


0

Eu tive o mesmo problema no Linux Mint 17.3 Rosa.

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

  • Eu abro o terminal.
  • Entre como SU.
  • Use o topcomando e veja o PID de systemd.
  • Mate isso.

CPU voltou ao normal e o uso de RAM foi baixo. Claro que minha área de trabalho ainda está estável. Posso usar minha área de trabalho normalmente após essa operação.


Eu sempre pensei que systemd é sempre PID 1 0pointer.de/blog/projects/systemd.html
aventurin

0

Descobri que esse é um problema em algumas instalações do CentOS em execução no Hyper-V . Desativar o Integration Services nas configurações da VM parece ter resolvido isso. Especificamente sincronização de horário .

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.