27.10.2014 22:28, Lennart Poettering wrote:
On Mon, 27.10.14 22:22, Alexander E. Patrakov (patra...@gmail.com) wrote:
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.
Well, to my knowledge there is not efficient way to query this
information, so we probably shouldn't do that.
That's why I suggested doing it only when debugging is enabled via the
kernel command line. Otherwise, all this is left is guessing and code
audits - which is worse than the inefficient search for the smoking gun :)
If fsck is not the process that takes the locks, I bet LVM is. Are you
using that? Consider turning it off.
On this machine, LVM is not actually used, but is pulled in as a
dependency of udisks-2.1.3. And that dependency is conditional, on the
"cryptsetup" USE flag that is also useless on this desktop. So I think I
can indeed remove the "lvm" binary from this desktop (but not from the
Sony laptop). Thanks again!
--
Alexander E. Patrakov
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
