Score:2

Ubuntu 20.04.3 LTS systemd-udevd high CPU with CD/DVD rom drive

id flag

I know this question seems to be asked a lot in respect to wifi or bluetooth or nvidia but I'm struggling with an issue related to the cd-rom/dvd-rom.

I'm running Ubuntu on a Parallels VM and there is no physical DVD nor connected ISO image.

systemd-udevd ramps up to 100% CPU after a non-repeating time, i.e. there is no consistency on when it starts. It seemed to start when I updated Ubuntu-Base a couple of days ago. Using udevadm monitor I see the following:

KERNEL[26618.989007] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.020644] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.077203] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.200954] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
UDEV  [26619.233814] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.281478] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.312935] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.360996] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[26619.478767] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)
UDEV  [26619.504989] change   /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr0 (block)

which is repeated constantly.
dmesg information related to ata4 and sr0:

[    2.165687] ata4: SATA max UDMA/133 abar m8192@0xf0200000 port 0xf0200180 irq 30

[    2.808027] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    2.808812] ata4.00: ATAPI: Virtual DVD-ROM [1], FWR1, max UDMA/25
[    2.810047] ata4.00: configured for UDMA/25
[    2.811856] scsi 3:0:0:0: CD-ROM                     Virtual DVD-ROM  R103 PQ: 0 ANSI: 5
[    2.872450] sr 3:0:0:0: [sr0] scsi3-mmc drive: 44x/44x cd/rw xa/form2 cdda tray
[    2.872465] cdrom: Uniform CD-ROM driver Revision: 3.20
[    2.932438] sr 3:0:0:0: Attached scsi CD-ROM sr0

Looking at journalctl | grep 'systemd-udevd' I see the following potentially useful information:

Sep 09 17:15:01 ubuntu-vm systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)!
Sep 09 17:15:01 ubuntu-vm systemd[1]: systemd-udevd.service: Killing process 205157 (systemd-udevd) with signal SIGABRT.
Sep 09 17:15:01 ubuntu-vm systemd-udevd[205158]: sr0: Spawned process 'cdrom_id --eject-media /dev/sr0' [205517] is taking longer than 59s to complete
Sep 09 17:15:01 ubuntu-vm systemd-udevd[205158]: sr0: Spawned process 'cdrom_id --eject-media /dev/sr0' [205517] timed out after 2min 59s, killing
Sep 09 17:15:01 ubuntu-vm systemd-udevd[205158]: sr0: Process 'cdrom_id --eject-media /dev/sr0' terminated by signal KILL.
Sep 09 17:15:01 ubuntu-vm systemd-udevd[205158]: sr0: Failed to wait for spawned command 'cdrom_id --eject-media /dev/sr0': Input/output error
Sep 09 17:15:01 ubuntu-vm systemd-udevd[205158]: sr0: Failed to execute 'cdrom_id --eject-media /dev/sr0', ignoring: Input/output error
Sep 09 17:15:02 ubuntu-vm systemd[1]: systemd-udevd.service: Main process exited, code=dumped, status=6/ABRT
Sep 09 17:15:02 ubuntu-vm systemd[1]: systemd-udevd.service: Killing process 205158 (systemd-udevd) with signal SIGKILL.
Sep 09 17:15:02 ubuntu-vm systemd[1]: systemd-udevd.service: Killing process 205192 (systemd-udevd) with signal SIGKILL.
Sep 09 17:15:02 ubuntu-vm systemd[1]: systemd-udevd.service: Failed with result 'watchdog'.
Sep 09 17:15:02 ubuntu-vm systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 5.
Sep 09 17:15:02 ubuntu-vm systemd[1]: systemd-udevd.service: Found left-over process 205158 (systemd-udevd) in control group while starting unit. Ignoring.

This sequence of messages appears occasionally and it looks like a process is being started to eject a cd-rom. sr0 is not mounted.

I can kill the process but it will eventually restart and I don't want to keep doing that. I also don't really want a 'sticking plaster' to stop it as I may want to mount a DVD or ISO image but in any case, it would be nice to identify what may be causing the system to start working with sr0 and stop it.

I'm not really very proficient with Linux - I'm using it for specific development tools - and I've investigated what I could, but any help would be gratefully received.

EDIT: Killing the process is a temporary fix because it is re-started immediately albeit at a low CPU % from where it starts to ramp up. Running these commands (as per udevadm man entry) will stop the problem:

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

So it feels like it might be a boot order thing? Perhaps something not initialised before interaction with the CD-ROM device? Any way to tell?

Thanks,

Andrew

kp flag
This looks like the same issue listed on the Parallels forum: https://forum.parallels.com/threads/issue-with-parallels-ubuntu-vm-and-the-cd-rom.354750/
Score:2
id flag

Who knows what actually caused this to start. Given no response, this is what I have done.

Created a script in /usr/local/bin and made it executable:

#!/bin/bash
# Restart systemd-udevd to prevent runaway CD-ROM service

systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket
sleep 1

systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

Created a Systemctl service in /etc/systemd/system:

[Unit]
Description=Stop CD-ROM runaway service
After=graphical.target

[Service]
Type=simple
ExecStart=/usr/local/bin/stopCdRomNotifications.sh

[Install]
WantedBy=default.target

Then enabled it with:

sudo systemctl enable [myscriptname]

Now on booting, the runaway systemd-udevd process is stopped and then restarted in a non-runaway state. Without the sleep 1 statement in the script, it won't work: I surmise it is in an 'about to stop' state when asked to start again so it doesn't bother stopping first! A millisecond or microsecond delay may work, I didn't bother trying.

This is a bit of a sticking plaster in my opinion but I can't work out why this should suddenly start happening except that maybe the most recent update to Ubuntu-Base has caused it. Meh, Linux.

EDIT: I now have a root cause but no non-sticking-plaster answer. This problem is caused by a Parallels configuration for the VM together with kernel version 5.11.0.34. If I configure the VM to have no connected CD/DVD the 'runaway' systemd-udevd process starts; if I configure it with an attached ISO image then it doesn't. Booting into an earlier version of the kernel shows no issue, it is this kernel version plus a 'disconnected' CD/DVD that causes the problem. The answer, at the moment, is to configure the VM with a connected ISO image. This also fixes a 2-minute boot delay when launching the VM.

kp flag
Thanks for your question and answer - You're not alone: I've had the same issue on ubuntu 20 on latest parallels, but you've got far further than me with diagnosis and fix :D I've also got the 2 minute boot delay, and the thrashing systemd-udevd after [some magic time]. Hopefully we can find a "proper" fix
jp flag
i have exactly the same issue and only encountered it after moving from ubuntu 20.04 to ubuntu 21.04 and upgrading to parallels 17.0.1 (51482) from their last major version. looked at your script then noticed your edit about the disconnected CDROM device, so for now have connected the parallel tools ISO and will monitor to if it improves, had also noticed the very long boot delays
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.