[systemd-devel] dev-root.device is not active, results in an umount spree

[Lennart Poettering]

On Thu, 14.05.15 12:51, Martin Pitt (martin.pitt at ubuntu.com) wrote:

> > This is very bad. As a harmless action like following:
> > 
> > # mount --bind /opt /opt
> > 
> > Results in opt.mount unit to be generated which BindsTo
> > dev-root.device, which is inactive, thus systemd tries to stop that
> > unit straight away, and umount fails and is retried infinitely...
> > effectively DoSing init.
> 
> As I mentioned before, simply ignoring /dev/root doesn't help in all
> cases, and hardcoding it in the code is a bit ugly.

It doesn't help in all cases? Which ones? Can you elaborate?

And why is this ugly?

/dev/root is special in the kernel. No sysfs device by that name ever
exists, it's pretty much a fixed string the kernel inserts into the
mount table for the root device specified on the kernel cmdline. It
never exists otherwise and hence it is the right logic to check for it
explicitly and ignore it explicitly. It gets particularly confusing
for btrfs file systems, since those are device-less file systems
nominally, but when you use them as root fs without inird, they
suddenly appear as device backed fs this way...

> The attached patch is a more general solution which stops creating
> dead stub .device units for devices which don't exist at all. I. e.
> while in your case -.mount was probably BindsTo=dev-root.device (or in
> my case, in my container I had mnt.mount BindsTo=dev-sda3.device,
> which exists on the host but not in the container), but with this
> patch it should now not be bound to anything.

The patch is not right, Because it will not load device units for
devices that have not been referenced yet. This would break things for
mount entries that carry no deps on their own, but only reference a
source device.

> Lennart, if you don't like this there is an alternative, and more
> complicated solution: We could instead teach device_found_node() to
> actually do create a proper .device with the passed DeviceFound (which
> is "MOUNT"), resulting in creating a state "tentative" device. I have
> a half-working patch for this, but it's brittle as with pretty much
> any uevent or moutinfo change the status changes back to "dead",
> causing the unmount attempt. IMHO this approach isn't conceptually
> correct either -- in such containers, if don't have the corresponding
> device nodes at all, we shouldn't try to react to hotplug events and
> clean up mounts. I. e. the "tentative" concept does not really apply
> there. But I have misunderstood the intent.

Hmm, not following I must admit.

Note though that for containers we do not longer create any device
dependencies anyway, see 47bc12e1ba35d38.

Lennart

-- 
Lennart Poettering, Red Hat