Re: [linux-lvm] [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)

Re: [linux-lvm] [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)

[Peter Rajnoha]

On 05/15/2014 11:38 PM, Lennart Poettering wrote:
> On Thu, 15.05.14 23:15, Andy Kittner (andy.kittner@gmail.com) wrote:
> 
>> | 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.
> 
>> | 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. 
> 
> 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.

-- 
Peter

Re: [linux-lvm] [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)

[Lennart Poettering]

On Mon, 19.05.14 10:13, Peter Rajnoha (prajnoha@redhat.com) wrote:

> > 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. 
> > 
> > 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.

> 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.

> 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

-- 
Lennart Poettering, Red Hat