[systemd-devel] Delaying device service creation

[Francis Moreau]

On 07/03/2015 01:22 PM, Lennart Poettering wrote:
> 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.

Smart, I didn't think about using /dev/disks/by-label.

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

Ok. Maybe an error or a warning for services that have ordering
dependencies on device such as Before=<device> would be useful.

Thanks for your clarification.