[SOLVED] udisksd using lots of CPU

[Colin 't Hart]

I'm having a problem that has been reported by other Debian and Ubuntu users that udisksd is using lots of CPU.

Right now I'm investigating workarounds rather than solutions so my question is: Is this service essential to Proxmox? What happens if I stop and disable it?

 

[Alwin]

udisks2 is by default not installed.

 

[Colin 't Hart]

Thanks. That tells me all I need to know. I'm using Proxmox as my workstation OS, so udisks2 was installed by the act of adding XFCE to the install. Will disable the udisks2 service as I almost never use USB disks and have no plans to add storage to my desktop machine.

 

[codejp3]

I ran across this as well. In my case, the udisks2 service was being used by Docker, Cockpit, and for mounting a USB external drive for manual backups.

udisks2 was consuming an average of 30-40% of my CPU at idle!

For now, I disabled Docker, Cockpit, and Udisks2, and my idle CPU is back down to 1-2% with several lxc containers running.

I suspect it's cockpit causing the CPU usage because it uses udisks2 heavily for anything related to drives, but I have not confirmed this yet.

The udisks2 version available in the Buster repo right now is pretty far behind and has known memory leaks and other issues that have since been patched, so perhaps a manual upgrade of that may fix it as well.

It would be nice to find the actual cause and correct it. If I do, I'll update this thread again with the fix.

 

[mkaatman]

Having this issue after pve 7.x upgrade.

apt-cache rdepends --installed udisks2

udisks2
Reverse Depends:
dbus-user-session
fwupd

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    877 root      20   0  394028  13156  10524 S  52.9   0.0  75:34.42 udisksd
    864 message+  20   0  146948 135496   4080 S  49.0   0.4  72:00.35 dbus-daemon

systemctl stop udisks2.service

Immediately drops the CPU to normal.

systemctl disable udisks2.service may be my solution for now.

 

[Crazyachmed123]

I can also see a spike in the load-average from about 1.5 do 7.5 after the update to PVE 7. Stopping udisks2 drops the numbers back down.

 

[astrakid]

i have those "spikes" for hours (it is not a spike anymore). i am running systemctl stop udisks2 via crontab every 10 minutes.
what is a real solution? why are udisks2 generating high cpu?

regards,
andre

 

[daftlink]

Hello
Same here.. I don't know if it's related to my External HDDs: WD Digital and Seagate Expansion.

I stop udisk, I hope there will not be a lot of side effects

NB: Version 6.4-13

 

[marcwittke]

Have seen this on every reboot on my proxmox-ve 7 that is also our mediacenter in the livingroom (KDE Plasma & kodi)

restarting systemd-udevd stops the disk and cpu load immediately. So I logged in as root, issued crontab -e and added this line

@reboot sleep 60 && systemctl restart systemd-udevd

to restart systemd-udevd 1 minute after reboot. Problem solved, somewhat... This type of machine is fine with it.

 

[Lee Kuper]

Fix the problem in my case the following string:

ACTION=="add|change", KERNEL=="dm-*", OPTIONS:="nowatch"

in file /etc/udev/rulesd/90-fixdm.rules

and then command:

systemctl restart udev

 

[kleinhirn]

I had the same problem, with udisks2 and related tasks using up to 25% CPU on my 12-core-system near constantly. The workarounds above both worked for me (Lee Kuper's an mkaatman's) with CPU load instantly dropping to near zero, but disabling/crippling udisks2 wasn't my preferred solution.
Checking udisks2's status repeatedly brought the following errors:

The function 'bd_crypto_luks_get_metadata_size' called, but not implemented!
Error getting '/dev/sda' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1)

After a simple apt install libblockdev-crypto2 I was able to restart/re-enable udisks2 and remove Lee Kuper's workaround, with CPU load staying near zero.

I am using proxmox on a fully LUKS-encrypted server, so this problem and it's solution may be unique to my situation.

 

[Zoker]

For me it was the usage of `fwupd`. As soon as I removed that, my CPU usage returned to a normal level again.
Here is what my CPU usage (of a i5 9500T) looks like after removing the udisks packaged, that was installed by fwupd:

 

[LarsNorgaard]

Do we have any idea why it consumes so many cpu cycles?

On my system it got installed, when I installed fwupd. Removing that and doing an autoremove after fixed the problem.

 

[fweber]

Hello, AFAICT it's a udisks2 bug, see here (comment 3) for more information: https://bugzilla.proxmox.com/show_bug.cgi?id=4629#c3

 

[Colin 't Hart]

Hello, AFAICT it's a udisks2 bug, see here (comment 3) for more information: https://bugzilla.proxmox.com/show_bug.cgi?id=4629#c3

Why has that bug been marked as "Resolved invalid"? By your own admission it's a bug -- even if it's a problem caused by an upstream package. Seems the bug has been fixed upstream, but there's no new release of udisks2 yet. Does/can Debian/Proxmox include the patch that fixes it? https://github.com/storaged-project/udisks/pull/949

 

[fiona]

Hi,

Why has that bug been marked as "Resolved invalid"? By your own admission it's a bug -- even if it's a problem caused by an upstream package. Seems the bug has been fixed upstream, but there's no new release of udisks2 yet. Does/can Debian/Proxmox include the patch that fixes it? https://github.com/storaged-project/udisks/pull/949

because there currently is no NOTOURBUG status in our bugtracker, so INVALID makes the most sense. Proxmox VE doesn't ship with udisks2, it's not part of our software stack. You have to install it manually yourself. When Debian will include the fixed version, you will get it.

 

[triks]

purely noticed CPU utilisation at 60% with no containers running - thankfully found this post.

Don't use USB at all so ran

systemctl disable udisks2.service

(thx mkaatman) and instantly CPU utilisation is fluctuating at 0.5% to 1.59%!

Seems to stick after reboot but idk if there will be any other consequences - can't believe this is not being worked on, surely its a bug wasting resources.

 

[fiona]

Hi,

can't believe this is not being worked on, surely its a bug wasting resources.

it is being worked on. Upstream does include the fix already and Debian should get it too at some point. But it's not a package Proxmox VE ships, suggests or maintains.