27.10.2014 22:13, Lennart Poettering wrote:
On Mon, 27.10.14 21:57, Alexander E. Patrakov (patra...@gmail.com) wrote:
27.10.2014 21:49, Lennart Poettering wrote:
On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
