14

I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in 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

Why might systemd-udev be hammering the CPU? This is a Kubuntu 14.10 system:

$ 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: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.

As per Bratchley's suggestion, here is the strace of the systemd-udev process with ID 359.

  • 2
    You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it. – Bratchley Oct 1 '15 at 20:22
  • 1
    @Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated. – dotancohen Oct 1 '15 at 21:18
  • 1
    Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command? – Bratchley Oct 2 '15 at 15:13
  • 1
    I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes. – dotancohen Oct 2 '15 at 15:19
  • 2
    Is there anything shown when you run "udevadm monitor" ? – V13 Oct 2 '15 at 16:04
14

It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules

Look for a couple of lines that look like this (at the end of the file):

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

Comment the second line by putting a # before ENV, so that it looks like:

#ENV{ID_MTP.... 

Restart your computer or run sudo systemctl restart systemd-udevd and enjoy your free CPU cycles :)

  • Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately. – Nate Glenn Mar 31 '17 at 7:10
8

Use udevadm monitor to find out which driver is pooling the cpu.

  • OK. I think I found the device. What now? – norok2 Mar 16 at 12:57
4

Another cause:

  1. Installed nvidia driver 396
  2. Restart with blank screen
  3. Disabled nvidia in bios
  4. System works with Intel, but after several sleep/resume I got this from udevadm monitor (random lines but repeating all the same indefinitely):

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

I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.

  • 1
    I ran into the same problem. uninstalled Nvidia drivers solved the problem. – TC Zhang Oct 4 '18 at 5:31
1

There is a bug in the kernel that cause systemd-udevs 100% CPU usage.

So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.

This work fine for me.

1

The solution proposed by eLobato did not worked for me.

With the same sympthoms described, I found this thread: https://askubuntu.com/questions/1073185/after-upgrade-from-ubuntu-16-to-18-04-systemd-udevd-uses-100-cpu

that solved the issue for me. I repeat the solution below for completeness, but all credits goes to the original answer by brunom4ciel.


Try if stopping and starting the processes solves the problem with no undesired side effects:

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

If this works embed it in a script under /etc/init.d/systemd-udevd-solv.sh with:

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

and paste:

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

Then change permission to be executed at login

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

I had the same problem on Linux Mint 17.3 Rosa.

To solve it, when my PC is idle:

  • I open up terminal.
  • Login as SU.
  • Use top command and see PID of systemd.
  • Kill it.

CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.

0

I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.