[systemd-devel] Delaying device service creation

[Lennart Poettering]

B1;4002;0cOn Fri, 03.07.15 13:09, Francis Moreau (francis.moro at gmail.com) wrote:

> > That's not an issue really. Since the device will not have any disk
> > label initially, and thus nothing will make use of it, until the
> > mke2fs is finished, and an ext2 label applied. When mke2fs then closes
> > the device, udev notices this (via inotify), will retrigger the
> > device.
> > 
> 
> Does that mean that a mount service (having Where=<device-node>) waiting
> for that device is not waiting for the device to appear but is waiting
> for a valid FS on this device ?

Well, depends. 

Basically, if you reference the device by the raw device node name
then, no it will not wait. But if you reference the device by a
higher-level name, involving bits from the disk label (such as using
/dev/disks/by-label/xyz symlinks), then yes, it will wait, since that
symlink doesn't exist until the mke2fs is done.

> But in the case of cryptsetup with 'tmp' option, the device can have a
> disk label initially, since it's reformatted at each boot.

hmm, usually "tmp" is combined with a /dev/urandom key, and hence is
effectively empty initially...

This might be broken if you indeed use a fixed key each time, so that
the old disk label is still visible initially.

> Systemd can't do little with the HW event but it can choose the moment
> when the device unit is created or is marked with an 'active' state and
> also choose when all the device deps are started.

well, but it doesn't work that way... we do not delay device
state changes until all the deps are fulfilled, and I am not convinced
we should. It's the general logic we follow: ordering deps control
only the state changes systemd itself triggers, but do not affect
systemd's view of external events. They only affect the order in which
we process the job queue, but they are irrelevant for the actual
states of the units. 

Lennart

-- 
Lennart Poettering, Red Hat