[systemd-devel] Delaying device service creation

[Francis Moreau]

On 07/03/2015 12:18 PM, Lennart Poettering wrote:
> On Fri, 03.07.15 11:53, Francis Moreau (francis.moro at gmail.com) wrote:
> 
>> On 07/03/2015 11:08 AM, Lennart Poettering wrote:
>>> On Tue, 30.06.15 17:37, Francis Moreau (francis.moro at gmail.com) wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a service 'A' which creates a device 'X' and does some
>>>> configuring of the device. The device is created in a 'ExecStart='
>>>> directive whereas its configuration happens during 'ExecStartPost='.
>>>>
>>>> But it seems that as soon as the device is seen by systemd, it creates
>>>> the corresponding device service and starts all services that depeneds
>>>> on this device.
>>>
>>> What kind of a device is this? block device?
>>
>> Yes, it's a block device which needs some initialization before being
>> mounted.
>>
>> Actually I found a similar case with cryptsetup:
>>
>> $ cat systemd-cryptsetup\@cr_tmp.service
>> ...
>> [Service]
>> Type=oneshot
>> RemainAfterExit=yes
>> ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'cr_tmp' '/dev/vdb'
>> 'none' 'tmp'
>> ExecStartPost=/sbin/mke2fs '/dev/mapper/cr_tmp'
>> ...
>>
>> Basically command in ExecStart will create the device and systemd will
>> create the corresponding device unit file and will start all deps which
>> are waiting for this device. Mount service can be one of them. Note that
>> this happens while the device creation service is still not finished.
>>
>> Then systemd will execute ExecStarPost command while device's deps are
>> running which is incorrect since you can end up with mount trying to
>> operate on a fsck'ed FS.
> 
> You mean "trying to operate on an FS that is currently being created"?
> 
> 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 ?

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

This is what I'm getting when trying to mount a crypted device with
'tmp' option and fsck enabled in fstab (I must admit that running fsck
is useless in that case but:

systemd[1]: Found device /dev/mapper/cr_tmp.
systemd[1]: Starting File System Check on /dev/mapper/cr_tmp...
systemd-fsck[366]: /dev/mapper/cr_tmp: clean, 11/25688 files,
4800/102400 blocks
systemd[1]: Started File System Check on /dev/mapper/cr_tmp.
systemd[1]: Mounting /mnt/cr_tmp...
systemd[1]: Mounted /mnt/cr_tmp.
systemd[1]: Starting Local File Systems.
systemd[1]: Reached target Local File Systems.
systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
kernel:	EXT4-fs (dm-1): mounting ext2 file system using the ext4 subsystem
kernel:	EXT4-fs (dm-1): mounted filesystem without journal. Opts: (null)
systemd[1]: Starting Recreate Volatile Files and Directories...
mke2fs[364]: mke2fs 1.42.8 (20-Jun-2013)
mke2fs[364]: /dev/mapper/cr_tmp is mounted; will not make a filesystem here!
systemd[1]: systemd-cryptsetup at cr_tmp.service: control process exited,
code=exited status=1
systemd-journal[185]: Runtime journal is using 524.0K (max 49.8M,
leaving 74.7M of free 497.
systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
systemd[1]: Started Recreate Volatile Files and Directories.
systemd[1]: Starting Update UTMP about System Reboot/Shutdown...
systemd[1]: Started Update UTMP about System Reboot/Shutdown.
systemd-cryptsetup[378]: Failed to deactivate: Device or resource busy
systemd[1]: systemd-cryptsetup at cr_tmp.service: control process exited,
code=exited status=1
systemd[1]: Failed to start Cryptography Setup for cr_tmp.
systemd[1]: Dependency failed for Encrypted Volumes.
systemd[1]: Unit systemd-cryptsetup at cr_tmp.service entered failed state.

In this case the device is mounted before mke2fs had a chance to run.


>>> You should mark your device with SYSTEMD_READY=0 in udev, as
>>> long as it is not ready to be exposed. Check 99-systemd.rules for a
>>> few examples where we do this for loopback or mdadm devices as long as
>>> they are not fully set up.
>>>
>>
>> Noted, I'm going to have a look at how this works.
>>
>> That said it's still not clear to me if a service can delay the device
>> service availability. IOW does something like below is supposed to work:
>>
>> $ cat my-device-creation.service:
>> ...
>> Before=my-device.device
>> ...
>>
>> >From my basic testing, it doesn't seem supported.
> 
> No it's not. Devices appear and disappear independently of
> dependencies... I mean, if you plug in a USB pen drive, then you
> plugged it in, and that fact won't change because you actually want a
> service to run first. it just happened anyway... and systemd accepts
> that, basically.
> 
> If you have ordering deps between a device and a service unit, then
> this has little effect on the device unit, but a lot of effect on the
> service unit. The service unit is something systemd can order, and
> where it controls when to start/stop the thing. But a device is
> nothing systemd can order, it just has to accept the order of the hw
> events.
> 

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.

Sorry I can't take a look at the SYSTEMD_READY=0 right now, but that's
probably an example of systemd not creating a device unit whereas an HW
event happened.

Thanks.