Dlaczego systemd-udev określa mój procesor?

Zauważyłem, że jeden z rdzeni czterordzeniowego laptopa jest ustalony, a temperatura jest bardzo wysoka. Znalazłem to w 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

Dlaczego może systemd-udevwbijać procesor? To jest system 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

EDYCJA: Zauważam, że oprócz ustalonego procesora istnieje dodatkowy problem. Nowo podłączone urządzenia USB, takie jak urządzenie pamięci masowej USB lub klawiatura, pojawią się w, lsusbale nie będą mogły zostać użyte. Urządzenie pamięci masowej nie jest montowane automatycznie, a klawiatura USB nie działa. Nie próbowałem ręcznie montować napędu USB.

Zgodnie z sugestią Bratchley jest, tutaj jest strace z systemd-udevprocesu o ID 359.

Wygląda na to, że libmtp znalazł urządzenie, ale nie jest w stanie prawidłowo go odłączyć i ciągle je sprawdza. Zdarza się to na niektórych urządzeniach i można je wyłączyć, edytując /lib/udev/rules.d/69-libmtp.rules

Poszukaj kilku linii, które wyglądają tak (na końcu pliku):

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

Skomentuj drugą linię, umieszczając # przed ENV, aby wyglądało to tak:

#ENV{ID_MTP.... 

Uruchom ponownie komputer lub uruchom sudo systemctl restart systemd-udevdi ciesz się wolnymi cyklami procesora :)

Użyj, udevadm monitoraby dowiedzieć się, który sterownik łączy procesor.

Inna przyczyna:

1. Zainstalowany sterownik nvidia 396
2. Uruchom ponownie z pustym ekranem
3. Wyłączono NVIDIA w bios

4. System działa z Intelem, ale po kilku uśpieniach / wznowieniu otrzymałem to udevadm monitor(losowe linie, ale powtarzam to samo w nieskończoność):

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

Nie jestem pewien, ale spodziewam się, że jest to spowodowane faktem, że sterownik nvidia jest aktywny, ale nvidia jest wyłączona w systemie BIOS.

Rozwiązanie zaproponowane przez eLobato nie zadziałało dla mnie.

Z tymi samymi opisanymi sympthoms znalazłem ten wątek: /ubuntu/1073185/after-upgrade-from-ubuntu-16-to-18-04-systemd-udevd-uses-100-cpu

to rozwiązało problem dla mnie. Powtarzam poniższe rozwiązanie dla kompletności, ale wszystkie kredyty trafiają do pierwotnej odpowiedzi brunom4ciel.

Spróbuj, jeśli zatrzymanie i uruchomienie procesów rozwiąże problem bez niepożądanych skutków ubocznych:

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

Jeśli to działa, umieść go w skrypcie w /etc/init.d/systemd-udevd-solv.sh:

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

i wklej:

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

Następnie zmień uprawnienia do wykonania podczas logowania

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

W jądrze jest błąd, który powoduje 100% użycie procesora przez systemd-udevs.

Tak więc obejście polega na ponownym uruchomieniu systemu, naciśnięciu i przytrzymaniu klawisza Shift podczas ładowania Grub. Następnie wybierz starsze jądro z listy bootloadera.

To działa dobrze dla mnie.

Miałem ten sam problem na Linux Mint 17.3 Rosa.

Aby rozwiązać problem, gdy mój komputer jest bezczynny:

• Otwieram terminal.
• Zaloguj się jako SU.
• Użyj toppolecenia i zobacz PID z systemd.
• Zabij to.

Procesor wrócił do normy i zużycie pamięci RAM spadło. Oczywiście mój pulpit jest nadal stabilny. Po tej operacji mogę normalnie korzystać z pulpitu.

Odkryłem, że jest to problem występujący w niektórych instalacjach CentOS działających na Hyper-V . Wygląda na to, że wyłączenie usług integracji w ustawieniach maszyny wirtualnej rozwiązało problem. W szczególności synchronizacja czasu .