Re: [systemd-devel] Delaying device service creation
On 07/03/2015 01:22 PM, Lennart Poettering wrote: B1;4002;0cOn Fri, 03.07.15 13:09, Francis Moreau (francis.m...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
On Fri, 03.07.15 14:25, Francis Moreau (francis.m...@gmail.com) wrote: 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. Indeed, I think we should indeed warn in this case. Added to the TODO list now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
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 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. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
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
Re: [systemd-devel] Delaying device service creation
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? 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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
On 07/03/2015 12:18 PM, Lennart Poettering wrote: 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. 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@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@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@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
Re: [systemd-devel] Delaying device service creation
B1;4002;0cOn Fri, 03.07.15 13:09, Francis Moreau (francis.m...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
On 06/30/2015 07:47 PM, Mantas Mikulėnas wrote: Options: - Configure it as part of ExecStart if possible. I don't see how is this going to help, sorry. - Configure it using a second .service unit (oneshot), and depend on that one. You meant all services that were depending on the device should depend on that second .service ? I so, I would rather avoid that: it seems much cleaner to me to have the device service started once the configuration has been done, ie when the device really ready. Actually my question is rather : does adding dependencies on device services is supported, so I can make it 'appear' only when the service which creates and configures it is completely finished ? - Do something with udev to mark unconfigured devices with SYSTEMD_READY=0? Not sure how. But if you can do this, it'll directly affect the readiness of the corresponding .device unit. I have to see how to do that and how to set SYSTEMD_READY=1 once configured. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Delaying device service creation
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. However this happens even if service 'A' hasn't finished to configure the device yet. I tried to add 'Before=X.device' in 'A' service file, but it doesn't seem to have any effects. Could anybody help me ? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
Options: - Configure it as part of ExecStart if possible. - Configure it using a second .service unit (oneshot), and depend on that one. - Do something with udev to mark unconfigured devices with SYSTEMD_READY=0? Not sure how. But if you can do this, it'll directly affect the readiness of the corresponding .device unit. On Tue, Jun 30, 2015, 18: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. However this happens even if service 'A' hasn't finished to configure the device yet. I tried to add 'Before=X.device' in 'A' service file, but it doesn't seem to have any effects. Could anybody help me ? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
