CPU high process by systemd-udevd when switching AC / Battery on laptop

I noticed that when I connect the AC_Adapter to my Thinkpad X1 carbon that the fan went full-throttle and CPU temp goes up to 76C and maybe more if I let it.
Using top I saw "systemd-udevd" maxing out 2 cores.
"udevadm monitor" tells me it's bluetooth/hci connected ....
It turns out using
"sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket && sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket"
solves the problem ... until I connect again. Then it has to be run again or I simply dont run the start bit, but then I suspect I will not have bluetooth.

Hope this helps anyone having the same problem and ,maybe it'll be gone in newer kernel releases.


Intrerestingly just using the stop command and resuming from suspend (using dpms) ..... if the touchpad is lost, using a previous solution:
"sudo modprobe -r psmouse;sudo modprobe psmouse" doesn't work. It requires a start of the sockets first. :face_with_raised_eyebrow:

1 Like

hum, this sounds like a very specific (hardware) issue :thinking: , FAQ section ?

so what is the process using this much cpu ?

It is (or was).
The laptop started having issues that it wouldn't shutdown through the OS i.e it kept booting up again spontaneously...as if the power button was stuck. :eyepopping:

If I did shutdown the machine by holding the power button for a long time, it wouldn't boot at all without the reset button (a small hole in the bottom) and the resetting time and date in the BIOS -- as if the battery had disconnected.

Eventually I opened the machine and found another (very, very small) button, similar to the reset button near one of the hinges and after pressing that (5 sec or so) --- everything was back to normal after the next reboot.
"Normal" meaning no more systemd-udevd hogging the CPU and proper shutdown procedures.:boogie:

Systemd and pulseaudio can due to wrong design consume alot of cpu and memory resurses.

Best way to solve this, specially for embedded systems is to remove then or shorten then out.

I have used many other Linux and -BSD system and there specially for Linux (latest CentOS7 or RedHat) systemd and pulseaudio has misbehaved in normal, suspend or hibernate or from resume, even from power up. It's not normal action to loop forever and consume too much cpu resources as the do today if wrong configuration. This can kill any embedded with battery support. Best solution is to do as MX linux (wrapper around) or better AntiX Linux (removed) do today. Then this wrong behavior is also removed. Previous version did not used systemd or pulseaudio. There are also problems with pulseaudio usage with increased latency dependent of audio source, my audio mixing software also misbehave and results will be trash.

comment mentioned in: Systemd VS Sysvinit

hah! I just got the same issue (but when booting without AC instead)

happens with kernel 4.19 but not with the 5.5 kernel

do you think is related to bluetooth? :thinking: i need to investigate more this... going to do a few reboots with tests to isolate the issue...

to be continued...

In my case there was something wrong with the hardware or firmware (or both).
Doing a total reset of the motherboard (flush CMOS) solved the issue....but I have no idea what the reasons were or why, although I do suspect it has to do with how the "on/off" button is programmed in the firmware.

hum... since the issue happens on my computer too, maybe is not really a hardware issue (or maybe it was a bios setting!)

in any case, try to have "laptop-mode-tools" package installed and running 4.19, this is the way to reproduce it, or more exactly, don't have this combination lol

This issue only happens with the 4.19 kernel apparently AND by having the laptop-mode-tools package installed

To solve it easily, i suggest to install Elive using the updated kernel, or to remove the laptop-mode-tools package (which will make you lose the benefits of power saving on battery mode)

moved to category #system:bugs

We will need to know if this issue happens to more people or only us :thinking: (Thinkpad T460s here, yours is Thinkpad X1 carbon), in order to know the severity of the issue

At the time, I searched around and it has happened to others albeit not many with no real clear cause.
The only thing I find sort of alike was an issue my daughters Thinkpad Helix2 sometimes had: It would freeze and on shutdown wouldn't boot up again, requiring a physical reset (through a little hole) of the motherboard.
The X1 carbon had a pinhole that didn't help but a second "CMOS-reset/clear" button hidden away on the MB eventually did the trick.
Since then I've never had the issue again ....so could be a kernel thingy :thinking: