[systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again

[Alexander E. Patrakov]

27.10.2014 22:13, Lennart Poettering wrote:
> On Mon, 27.10.14 21:57, Alexander E. Patrakov (patrakov at gmail.com) wrote:
>
>> 27.10.2014 21:49, Lennart Poettering wrote:
>>> On Mon, 27.10.14 21:46, Alexander E. Patrakov (patrakov at gmail.com) wrote:
>>>
>>>> Some time ago, I have complained that some boots are unsuccessful, because
>>>> the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
>>>> should point to /dev/sda2) is not created by udev in the initramfs (which
>>>> uses dracut). Thankfully, people on IRC have suggested some useful debugging
>>>> options:
>>>>
>>>> systemd.log_level=debug rd.udev.log-priority=debug
>>>>
>>>> So now I have a SOS report. It is over 1 MB, so not attached. The useful
>>>> lines are:
>>>>
>>>> [    3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
>>>> skipping event handling: Resource temporarily unavailable
>>>> [    3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
>>>> skipping event handling: Resource temporarily unavailable
>>>>
>>>> Let me complain here that these error messages still don't contain the
>>>> complete picture. How am I supposed to know which program in my
>>>> dracut-created initramfs locks /dev/sda and interferes with udev event
>>>> handling?
>>>
>>> Most likely you are either using a too old util-linux, whose use of
>>> BSD locks conflict's with udev's use of it. (fsck -l)
>>>
>>> Please always check README, it will let you know precisely which
>>> release of util-linux you need at least.
>>
>> I use fsck from util-linux 2.25.1. Verified by extracting the initramfs.
>> According to the README, this version should be OK, so it must be something
>> else.
>
> Hmm, please use "lslocks" or /proc/locks to figure out which process
> might have the device nodes locked.

Thanks for the pointer. It is good to know that the information is 
available in the kernel.

Unfortunately, it is not possible to run the lslocks program manually or 
see the contents of /proc/locks exactly at the moment when some stupid 
program decides to lock the device. Especially since this does not 
happen at every boot.

I think that printing the equivalent of the lslocks output directly from 
udevd when failing to lock the device would be a useful debugging aid. 
Of course, this feature request only applies when udev.log-priority=debug.

-- 
Alexander E. Patrakov