cryptsetup vs. swapon/fsck (some kind of race condition)

linux-lvm Peter Rajnoha 2 participants 2 messages May 19, 2014 – May 20, 2014 6 messages not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Peter Rajnoha

author

2014-05-19 08:13 UTC #6 lore raw

Quoted 25 lines · Lennart Poettering

Quoted 2 lines · Andy Kittner
| May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory.
This looks like remains from a *really* old systemd version. THis does not exist anymore. What distribution is this?
This used to bind mount /run to /var/run, and similar for /var/lock.
Quoted 6 lines
| May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager.
| May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: open_queue_file failed with errno 2
| May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG libdm:_check_udev_is_running: Udev is not running. Not using udev synchronisation code.
So the udev queue file does not yet exist, libdm thinks the system is not running udev and things go wrong...
This really should be turned off in libdm. It's really stupid and broken. We start these things in parallel, they create these races without reason. Since ages we don't support non-devtmpfs kernels anymore, so it's *always* wrong to invoke mknod(), since the kernel will create the device nodes. Unless you run an early 2.6 kernels this is completely wrong. I'd recommend filing a bug against the distribution to remove this old crap from libdm.

Quoted 1 line

What does libdm even check there precisely?

It uses libudev's udev_queue_get_udev_is_active. So is there a better function we should use instead? If not, there should probably be a better one provided in libudev to check whether udev is ready to serve on the system or not.

As for devtmpfs, are you sure it's enabled everywhere and always? It's configurable for the kernel and one does not need to enable it it seems. I just need to be sure that if we completely turn this fallback node management in libdm, I won't cut someone off in some distro with settings not exactly the same as used in Fedora.

Signature · 1 line

Peter

Lennart Poettering

2014-05-20 16:16 UTC #7 lore raw

Quoted 7 lines · Peter Rajnoha

Quoted 7 lines
broken. We start these things in parallel, they create these races without reason. Since ages we don't support non-devtmpfs kernels anymore, so it's *always* wrong to invoke mknod(), since the kernel will create the device nodes. Unless you run an early 2.6 kernels this is completely wrong. I'd recommend filing a bug against the distribution to remove this old crap from libdm.

Quoted 6 lines

Quoted 1 line
What does libdm even check there precisely?
It uses libudev's udev_queue_get_udev_is_active. So is there a better function we should use instead? If not, there should probably be a better one provided in libudev to check whether udev is ready to serve on the system or not.

Well, whether udev is already running yet or hasn't been started yet doesn't actually matter much, as udev's APIs are completely safe regarding that. You can allocate a monitor before udev is up, and it will work but only start reporting things after udev is up. And you can enumerate devices, and the API will report with udev_device_is_initialized() whether that specific device is initialized yet, and this will return true only if udev not only got started but also processed the device.

The entire API is hence designed in a way that you don't need to synchronize against udev in order to use its APIs, hence the idea to check whether udev is running is completely against the entire design of it.

Quoted 1 line

As for devtmpfs, are you sure it's enabled everywhere and always?

Well, udev has been requiring that for a while, there's no code in udev anymore to even do a mknod() on its own...

If you think it is worth support really old kernels with new LVM (though I really don't see why you would want that, after all LVM is hardly an app you install but part of the OS itself), then at least make the mknod madness a compile-time configurable option, and set it to "off" by default, so that people understand that this is archaic stuff nobody in his right mind would ever use when setting up a system today. The Gentoo developers apparently need holding hands for these kinds of things, and this is how you can guide them into the right direction.

Quoted 4 lines

It's configurable for the kernel and one does not need to enable it it seems. I just need to be sure that if we completely turn this fallback node management in libdm, I won't cut someone off in some distro with settings not exactly the same as used in Fedora.

Well the kernel wants to support really archaic userspaces. I don't think that this really applies the same way for LVM.

Also, I am pretty sure that pretty much any distro from the last 2 years is using devtmpfs, since udev stopped supporting non-devtmpfs systems from jan 1st 2012 on. And you can be quite sure that actually they already adopted it much earlier, since that was just the time where we removed support for it in udev upstream, where we have the guarantee. Early than that we just strongly recommended it, and it was merged into the kernel in apr 30th, 2009.

Please, remove the old cruft! Or at least disable it by default int the code!

Thanks,

Lennart

Signature · 1 line

Lennart Poettering, Red Hat