Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote: [...] ...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck instances. Seems that sysroot.mount alone isn't sufficient. ...Anything on this? Should we add yet another passive target(s), something like fsck-pre? I don't actually know what is the best way to tackle this. The resume unit shall be activated before any writes to any block devices, including fsck, cryptsetup and whatever else. Hmm, so I though a bit about this, and I think we should make the following changes to systemd: a) move local-fs-pre.target before all the fsck. This way we can make use of it as a barrier against modifications of any fs. ...all fsck except the systemd-fsck-root.service, right? It's already ordered before local-fs-pre.target. Makes sense; then the resume unit will be Wants=local-fs-pre.target Before=local-fs-pre.target systemd-fsck-root.service systemd-remount-fs.service shutdown.target ConditionPathIsReadWrite=!/ However, this breaks when there is a legacy /usr mount without fsck... src/core/mount.c:mount_add_default_dependencies() does not add After=local-fs-pre.target if the mount in question is / or /usr. Hence, the legacy /usr mount is missed by this scheme. b) introduce initrd-fs-pre.target that then plays a similar role, but in the initrd. Is it neeeded? IIUC, local-fs-pre.target can be used in initramfs as well, the default dependency on this target is still generated on all mounts. (except in-initramfs /usr, see the above problem) A service that wants to run before any fs is touched should then order itself before both and everything should be good. If this makes sense, I would be happy to take a patch. I'd be willing to merge a good patch for a generator + mini-tool that parse the resume= option into systemd as well, btw. I've already implemented the generator and resume tool prototype. Sure, when we solve the dependencies problem, I'll submit this for inclusion. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thursday 21 August 2014 at 22:06:49, Ivan Shapovalov wrote: On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote: [...] ...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck instances. Seems that sysroot.mount alone isn't sufficient. ...Anything on this? Should we add yet another passive target(s), something like fsck-pre? I don't actually know what is the best way to tackle this. The resume unit shall be activated before any writes to any block devices, including fsck, cryptsetup and whatever else. Hmm, so I though a bit about this, and I think we should make the following changes to systemd: a) move local-fs-pre.target before all the fsck. This way we can make use of it as a barrier against modifications of any fs. ...all fsck except the systemd-fsck-root.service, right? It's already ordered before local-fs-pre.target. Makes sense; then the resume unit will be Wants=local-fs-pre.target Before=local-fs-pre.target systemd-fsck-root.service systemd-remount-fs.service shutdown.target ConditionPathIsReadWrite=!/ However, this breaks when there is a legacy /usr mount without fsck... src/core/mount.c:mount_add_default_dependencies() does not add After=local-fs-pre.target if the mount in question is / or /usr. Hence, the legacy /usr mount is missed by this scheme. Actually, I don't pretty understand the reasoning behind skipping the default dependencies on /usr mount (commit b24de9d2, but the commit message doesn't say much). So hypothetically there are three solutions of different ugliness and acceptability: - introduce yet another target (all-fs-pre.t?) - revert b24de9d2 - add explicit Before=usr.mount to the resume unit -- Ivan Shapovalov / intelfx / b) introduce initrd-fs-pre.target that then plays a similar role, but in the initrd. Is it neeeded? IIUC, local-fs-pre.target can be used in initramfs as well, the default dependency on this target is still generated on all mounts. (except in-initramfs /usr, see the above problem) A service that wants to run before any fs is touched should then order itself before both and everything should be good. If this makes sense, I would be happy to take a patch. I'd be willing to merge a good patch for a generator + mini-tool that parse the resume= option into systemd as well, btw. I've already implemented the generator and resume tool prototype. Sure, when we solve the dependencies problem, I'll submit this for inclusion. signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On 21/08/14 19:12, Ivan Shapovalov wrote: Actually, I don't pretty understand the reasoning behind skipping the default dependencies on /usr mount (Some of) the default dependencies require that /usr is mounted, so mounting /usr cannot depend on them, to avoid a cycle. (Or to put it the way round: normal, non-early-boot services should be able to assume that /usr is mounted so that they can rely on files in /usr/lib or /usr/share without explicitly declaring extra dependencies, which again means /usr can't depend on the default dependencies.) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thursday 21 August 2014 at 19:32:01, Simon McVittie wrote: On 21/08/14 19:12, Ivan Shapovalov wrote: Actually, I don't pretty understand the reasoning behind skipping the default dependencies on /usr mount (Some of) the default dependencies require that /usr is mounted, so mounting /usr cannot depend on them, to avoid a cycle. (Or to put it the way round: normal, non-early-boot services should be able to assume that /usr is mounted so that they can rely on files in /usr/lib or /usr/share without explicitly declaring extra dependencies, which again means /usr can't depend on the default dependencies.) Understood, thanks. (For the original discussion: so is it better to explicitly Before=usr.mount?) -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote: On Tue, 19.08.14 15:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Monday 18 August 2014 at 22:04:29, Ivan Shapovalov wrote: [..] Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. Well, in the initrd the root dir is mounted to /sysroot, which means you should be able to order yourself before sysroot.mount. Lennart ...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck instances. Seems that sysroot.mount alone isn't sufficient. ...Anything on this? Should we add yet another passive target(s), something like fsck-pre? I don't actually know what is the best way to tackle this. The resume unit shall be activated before any writes to any block devices, including fsck, cryptsetup and whatever else. Hmm, so I though a bit about this, and I think we should make the following changes to systemd: a) move local-fs-pre.target before all the fsck. This way we can make use of it as a barrier against modifications of any fs. b) introduce initrd-fs-pre.target that then plays a similar role, but in the initrd. A service that wants to run before any fs is touched should then order itself before both and everything should be good. If this makes sense, I would be happy to take a patch. I'd be willing to merge a good patch for a generator + mini-tool that parse the resume= option into systemd as well, btw. So I have the prototype ready, but it seems that udevd indirectly depends on remounting / read-write. systemd-remount-fs.service - systemd-sysusers.service - systemd-udevd.service This breaks the idea at least in the initramfs-less case (and also in the pathological case of including systemd-sysusers.service into initramfs). What would you suggest? -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Tue, 19.08.14 15:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Monday 18 August 2014 at 22:04:29, Ivan Shapovalov wrote: [..] Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. Well, in the initrd the root dir is mounted to /sysroot, which means you should be able to order yourself before sysroot.mount. Lennart ...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck instances. Seems that sysroot.mount alone isn't sufficient. ...Anything on this? Should we add yet another passive target(s), something like fsck-pre? I don't actually know what is the best way to tackle this. The resume unit shall be activated before any writes to any block devices, including fsck, cryptsetup and whatever else. Hmm, so I though a bit about this, and I think we should make the following changes to systemd: a) move local-fs-pre.target before all the fsck. This way we can make use of it as a barrier against modifications of any fs. b) introduce initrd-fs-pre.target that then plays a similar role, but in the initrd. A service that wants to run before any fs is touched should then order itself before both and everything should be good. If this makes sense, I would be happy to take a patch. I'd be willing to merge a good patch for a generator + mini-tool that parse the resume= option into systemd as well, btw. 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] Implementing resume from hibernation as a systemd unit file
On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). 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] Implementing resume from hibernation as a systemd unit file
On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. Well, in the initrd the root dir is mounted to /sysroot, which means you should be able to order yourself before sysroot.mount. 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] Implementing resume from hibernation as a systemd unit file
On Monday 18 August 2014 at 18:40:59, Lennart Poettering wrote: On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. Well, in the initrd the root dir is mounted to /sysroot, which means you should be able to order yourself before sysroot.mount. Lennart ...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck instances. Seems that sysroot.mount alone isn't sufficient. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Friday 15 August 2014 at 15:35:06, Ivan Shapovalov wrote: [...] Ah, right. This is actually correct here. We want to make sure that the root fs is remounted before we mount the other units, since this might required creating additional directories to mount things on... There are two more complications: a) if you want to make use of local-fs-pre.target you actually have to pull it in, it's a passive unit. See systemd.special(5). b) You want to run your stuff before fsck is run on the devices, so that you don't end up interrupting an fsck that is half in progress. To put this together, in your unit file you need: Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). Lennart One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. This can be solved by introducing two resume units (say, systemd-resume@.service and initrd-resume@.service), first with Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target ConditionPathIsReadWrite=!/ and the second one with ConditionPathExists=/etc/initrd-release # something else ? BTW... are you sure that the second variant (in initramfs) does not require something to order before sysroot.mount and all fsck units?.. Actually, in case of initramfs these dependencies are not enough. In case of initramfs, there is no apparent way to order before all mounts and their fsck instances, especially given that there are no equivalents of systemd-remount-fs.service and systemd-fsck-root.service. Or do I miss something? Could you (someone) please give an advice? I'm also uncertain whether having two units (for initramfs and for real root) is the only way. Thanks, -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thursday 14 August 2014 at 12:56:10, Lennart Poettering wrote: On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote: The udev rule should be possible (provided that udevd does not need rootfs remounted read-write -- I'd like to preserve some decency towards initrd-less systems), but udev is a framework for handling events, whereas we don't have any events here: such symlink can be derived from kernel command-line alone, statically. udev is totally fine with read-only everything. It just needs writable /run. Yes, a udev rule would allow to create a symlink which is tracked by systemd, so the dev-disk-resume.device appears and then it can be easily After='ed from the resume unit, but... really, is udev the proper tool for this? The symlink thing we already do in a very similar way for the gpt auto root logic (see 60-persistent-storage.rules) already, so there's prior art. Understood. So there's a helper (ata_id) ran by IMPORT which sets ID_PART_GPT_AUTO_ROOT, and then this variable is used to match against... Looks beautiful, but here's a slightly another case. In context of hibernation/resume, the path to device node is already explicitly specified as a kernel cmdline parameter, and it could be anything from /dev/sdXY to /dev/disk/by-label/foo, so we can't use a helper to translate that path into a per-device flag (pathes for devices are generated after running helpers). So, IIUC, using udev is not an option here. Did I miss anything? If I didn't, are you OK with the generator + templated unit approach? Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. You could turn this into a generator, that pulls the switch from the kernel cmdline, and generates a service that orders itself before local-fs-pre.taret and after the device you need. The device you need you give a stable name via an udev rule. So is Before=local-fs-pre.target a sufficient ordering for such resume unit? Again, the resume unit must be started before any filesystems are (re)mounted read-write, either from initrd or not. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... Thanks, -- Ivan Shapovalov / intelfx / That's pretty much exactly how the got auto root thing works... Lennart signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote: Ah, well, if the resume= switch is supposed to simply carry the finished device node path, and nothing we still have to translate into one, then of course the entire udev rules step is unnecessary, and you can just write this out directly from the generator. Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. You could turn this into a generator, that pulls the switch from the kernel cmdline, and generates a service that orders itself before local-fs-pre.taret and after the device you need. The device you need you give a stable name via an udev rule. So is Before=local-fs-pre.target a sufficient ordering for such resume unit? Again, the resume unit must be started before any filesystems are (re)mounted read-write, either from initrd or not. Yes. That should be enough. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... That only runs after the transition into the host OS. 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] Implementing resume from hibernation as a systemd unit file
On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote: On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote: Ah, well, if the resume= switch is supposed to simply carry the finished device node path, and nothing we still have to translate into one, then of course the entire udev rules step is unnecessary, and you can just write this out directly from the generator. Yes, that's how it happens now. Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. You could turn this into a generator, that pulls the switch from the kernel cmdline, and generates a service that orders itself before local-fs-pre.taret and after the device you need. The device you need you give a stable name via an udev rule. So is Before=local-fs-pre.target a sufficient ordering for such resume unit? Again, the resume unit must be started before any filesystems are (re)mounted read-write, either from initrd or not. Yes. That should be enough. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... That only runs after the transition into the host OS. I'd like to make this work both with initramfs and without one (provided that the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter). In this case, what are the needed orderings? Thanks, -- Ivan Shapovalov / intelfx / Lennart signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Fri, 15.08.14 13:54, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote: On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote: Ah, well, if the resume= switch is supposed to simply carry the finished device node path, and nothing we still have to translate into one, then of course the entire udev rules step is unnecessary, and you can just write this out directly from the generator. Yes, that's how it happens now. Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. You could turn this into a generator, that pulls the switch from the kernel cmdline, and generates a service that orders itself before local-fs-pre.taret and after the device you need. The device you need you give a stable name via an udev rule. So is Before=local-fs-pre.target a sufficient ordering for such resume unit? Again, the resume unit must be started before any filesystems are (re)mounted read-write, either from initrd or not. Yes. That should be enough. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... That only runs after the transition into the host OS. I'd like to make this work both with initramfs and without one (provided that the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter). In this case, what are the needed orderings? Actually systemd-remount-fs.service uses After=local-fs-pre.target anyway, so ordering before l-f-p.t should be enough. 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] Implementing resume from hibernation as a systemd unit file
On Friday 15 August 2014 at 12:00:41, Lennart Poettering wrote: [...] So is Before=local-fs-pre.target a sufficient ordering for such resume unit? Again, the resume unit must be started before any filesystems are (re)mounted read-write, either from initrd or not. Yes. That should be enough. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... That only runs after the transition into the host OS. I'd like to make this work both with initramfs and without one (provided that the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter). In this case, what are the needed orderings? Actually systemd-remount-fs.service uses After=local-fs-pre.target anyway, so ordering before l-f-p.t should be nough. Hm. In git (v215-651-g41488fe), it is Before=local-fs-pre.target local-fs.target shutdown.target Wants=local-fs-pre.target -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Fri, 15.08.14 14:07, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Friday 15 August 2014 at 12:00:41, Lennart Poettering wrote: [...] So is Before=local-fs-pre.target a sufficient ordering for such resume unit? Again, the resume unit must be started before any filesystems are (re)mounted read-write, either from initrd or not. Yes. That should be enough. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... That only runs after the transition into the host OS. I'd like to make this work both with initramfs and without one (provided that the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter). In this case, what are the needed orderings? Actually systemd-remount-fs.service uses After=local-fs-pre.target anyway, so ordering before l-f-p.t should be nough. Hm. In git (v215-651-g41488fe), it is Before=local-fs-pre.target local-fs.target shutdown.target Wants=local-fs-pre.target Ah, right. This is actually correct here. We want to make sure that the root fs is remounted before we mount the other units, since this might required creating additional directories to mount things on... There are two more complications: a) if you want to make use of local-fs-pre.target you actually have to pull it in, it's a passive unit. See systemd.special(5). b) You want to run your stuff before fsck is run on the devices, so that you don't end up interrupting an fsck that is half in progress. To put this together, in your unit file you need: Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). 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] Implementing resume from hibernation as a systemd unit file
On Friday 15 August 2014 at 12:19:50, Lennart Poettering wrote: [...] I'd like to make this work both with initramfs and without one (provided that the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter). In this case, what are the needed orderings? Actually systemd-remount-fs.service uses After=local-fs-pre.target anyway, so ordering before l-f-p.t should be nough. Hm. In git (v215-651-g41488fe), it is Before=local-fs-pre.target local-fs.target shutdown.target Wants=local-fs-pre.target Ah, right. This is actually correct here. We want to make sure that the root fs is remounted before we mount the other units, since this might required creating additional directories to mount things on... There are two more complications: a) if you want to make use of local-fs-pre.target you actually have to pull it in, it's a passive unit. See systemd.special(5). b) You want to run your stuff before fsck is run on the devices, so that you don't end up interrupting an fsck that is half in progress. To put this together, in your unit file you need: Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). Lennart One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. This can be solved by introducing two resume units (say, systemd-resume@.service and initrd-resume@.service), first with Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target ConditionPathIsReadWrite=!/ and the second one with ConditionPathExists=/etc/initrd-release # something else ? BTW... are you sure that the second variant (in initramfs) does not require something to order before sysroot.mount and all fsck units?.. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote: The udev rule should be possible (provided that udevd does not need rootfs remounted read-write -- I'd like to preserve some decency towards initrd-less systems), but udev is a framework for handling events, whereas we don't have any events here: such symlink can be derived from kernel command-line alone, statically. udev is totally fine with read-only everything. It just needs writable /run. Yes, a udev rule would allow to create a symlink which is tracked by systemd, so the dev-disk-resume.device appears and then it can be easily After='ed from the resume unit, but... really, is udev the proper tool for this? The symlink thing we already do in a very similar way for the gpt auto root logic (see 60-persistent-storage.rules) already, so there's prior art. Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. You could turn this into a generator, that pulls the switch from the kernel cmdline, and generates a service that orders itself before local-fs-pre.taret and after the device you need. The device you need you give a stable name via an udev rule. That's pretty much exactly how the got auto root thing works... 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] Implementing resume from hibernation as a systemd unit file
On Mon, 28.07.14 14:06, Ivan Shapovalov (intelfx...@gmail.com) wrote: Hello all, I'm trying to implement resuming from hibernation with systemd-based initramfs, i. e. in terms of systemd unit files. That is, there should be a unit which waits for the resume device and writes its major:minor into /sys/power/resume. I've chosen to write a templated resume@path.service and a generator which parses 'resume=' kernel parameter and enables a corresponding instance of the resume@.service unit. The resume@.service itself shall be ordered so that it is activated when there are no filesystems mounted read-write, except tmpfs instances. It will be good if it works both from initramfs and from real rootfs (if it is mounted RO). So, here are some questions: - is it the way to go (overall)? - is it OK to use generators for outlined purpose? - how to order resume@.service and where to symlink it? I'm using Arch, if that matters -- but, IIUC, Arch strives to do everything in the upstream's way, so there should be no distro-specific details. I am not entirely sure how the hibernation logic precisely works, but wouldn't it be possible to write a little udev rule (maybe with a helper) that adds a special device node symlink to the resume partition, so that /dev/disk/resume or so always points to the resume partition to use? That udev rule should then maybe also pull in a unit that acts on it. But that unit doesn't have to be an instance, could just be a normal one... Does that make any sense? 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] Implementing resume from hibernation as a systemd unit file
On Thursday 14 August 2014 at 03:10:30, Lennart Poettering wrote: On Mon, 28.07.14 14:06, Ivan Shapovalov (intelfx...@gmail.com) wrote: Hello all, I'm trying to implement resuming from hibernation with systemd-based initramfs, i. e. in terms of systemd unit files. That is, there should be a unit which waits for the resume device and writes its major:minor into /sys/power/resume. I've chosen to write a templated resume@path.service and a generator which parses 'resume=' kernel parameter and enables a corresponding instance of the resume@.service unit. The resume@.service itself shall be ordered so that it is activated when there are no filesystems mounted read-write, except tmpfs instances. It will be good if it works both from initramfs and from real rootfs (if it is mounted RO). So, here are some questions: - is it the way to go (overall)? - is it OK to use generators for outlined purpose? - how to order resume@.service and where to symlink it? I'm using Arch, if that matters -- but, IIUC, Arch strives to do everything in the upstream's way, so there should be no distro-specific details. I am not entirely sure how the hibernation logic precisely works, but wouldn't it be possible to write a little udev rule (maybe with a helper) that adds a special device node symlink to the resume partition, so that /dev/disk/resume or so always points to the resume partition to use? That udev rule should then maybe also pull in a unit that acts on it. But that unit doesn't have to be an instance, could just be a normal one... Does that make any sense? Lennart The udev rule should be possible (provided that udevd does not need rootfs remounted read-write -- I'd like to preserve some decency towards initrd-less systems), but udev is a framework for handling events, whereas we don't have any events here: such symlink can be derived from kernel command-line alone, statically. Yes, a udev rule would allow to create a symlink which is tracked by systemd, so the dev-disk-resume.device appears and then it can be easily After='ed from the resume unit, but... really, is udev the proper tool for this? Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. Thanks, -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Implementing resume from hibernation as a systemd unit file
Hello all, I'm trying to implement resuming from hibernation with systemd-based initramfs, i. e. in terms of systemd unit files. That is, there should be a unit which waits for the resume device and writes its major:minor into /sys/power/resume. I've chosen to write a templated resume@path.service and a generator which parses 'resume=' kernel parameter and enables a corresponding instance of the resume@.service unit. The resume@.service itself shall be ordered so that it is activated when there are no filesystems mounted read-write, except tmpfs instances. It will be good if it works both from initramfs and from real rootfs (if it is mounted RO). So, here are some questions: - is it the way to go (overall)? - is it OK to use generators for outlined purpose? - how to order resume@.service and where to symlink it? I'm using Arch, if that matters -- but, IIUC, Arch strives to do everything in the upstream's way, so there should be no distro-specific details. Thanks, -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
