On Fri, 03.07.15 11:53, Francis Moreau (francis.m...@gmail.com) wrote: > On 07/03/2015 11:08 AM, Lennart Poettering wrote: > > On Tue, 30.06.15 17:37, Francis Moreau (francis.m...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
