[systemd-devel] Delaying device service creation
Lennart Poettering
lennart at poettering.net
Fri Jul 3 03:18:14 PDT 2015
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.
> > 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.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list