#93 Ejection of CDemu drive from nautilus causes high CPU usage by udevd

[Kyle Barbour]

Upon ejection of a CDemu-generated drive from the nautilus interface or Ubuntu launcher, CPU usage by udevd spikes substantially and lasts until reboot.

Replications steps:

1) Load .iso: cdemu load 0 image.iso
2) Unload .iso: cdemu unload 0
3) Right click on CD drive on the Ubuntu launcher and eject it (or eject it from nautilus)

The spike occurs immediately after the third step. It is not generated by loading or unloading the .iso from the command line. On my system this raises all four cores of my CPU to 30% - 50% usage. Specifically, this is geneated primarily from activation of systemd-udevd, udisksd, /sbin/init, udisks-daemon, init, and cdemu-daemon. See attachment for the top 20 highest CPU processes (generated by cropping $ top -n 1 -b > load.txt) so you can see the processes involved.

Killing the cdemu-daemon leads to resolution of the CPU load back to normal. See attachment #2 for a similarly cropped and generated output from top immediately after killing the cdemu-daemon process.

System information:

$ uname -a
Linux kamaji 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
$ cdemu version
Library version: 3.0.1
Daemon version: 3.0.1
$ lsmod | grep -i vhba
vhba 20480 1
$ ps -C cdemu-daemon
PID TTY TIME CMD
10423 ? 00:01:07 cdemu-daemon

My CDemu was downloaded from ppa:cdemu/ppa. I didn't see anything relevant in dmesg.

Any thoughts? Thanks!

[Kyle Barbour]

See these two attachements to clarify which ejection methods have been identified as leading to the above bug.

[Rok Mandeljc]

Hey Kyle,

thanks for the bug report. I have successfully reproduced the issue on my Ubuntu test setup, and will take a closer look at what's going on as soon as possible.

Regards,
Rok

[Rok Mandeljc]

Hey,

I found the cause of the problem, which is actually much more common and easier to trigger than it seemed.

Due to an incorrectly generated medium eject request event in the device unload codepath, issuing a START/STOP UNIT command on an empty device causes another medium eject request event to be generated. These events are picked up by udev/udisksd2 to unlock the device and eject it (when you press the eject switch on a physical device, the device's tray is typically locked by the OS, so it needs to be unlocked first, followed by a START/STOP UNIT command to eject the disc).

Therefore, issuing a START/STOP UNIT on an empty CDEmu device (for example, even via "eject /dev/srX"), causes endless loop of unload attempts, resulting in the CPU usage in both CDEmu daemon and udev/udisksd2 and related components that you observed.

The replication steps that you described cause this issue because step 2 actually empties the device, but due to a bug in one of components in Ubuntu 14.04, this is not registered. Therefore, you are left with the device icon for an empty device (same happens if you unload a physical device by pressing the hardware eject switch on the unit). So when you perform step 3, you are issuing eject command on an empty device...

I have pushed the fix to the git, and will create a bugfix release soon (need to check some things first, though) - in the mean time, skipping step 2 should do the trick.

Regards,
Rok

[Kyle Barbour]

Wonderful! Great job figuring this out so quickly - thanks very much!