Re: [systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
On Mon, 25.08.14 02:16, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. It adds: - a 'systemd-resume' tool which takes path to a device node and writes its major:minor to /sys/power/state; - a corresponding 'systemd-resume@.service' templated unit; - a 'systemd-resume-generator' generator which parses the kernel command line and instantiates the unit as necessary. This functionality already exists in-kernel, but only for /dev/sdXY-style pathes. Implementing it in userspace allows to use arbitrary udev-created symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar). Userspace parsing of resume= kernel command line parameter has been traditionally done in initramfs via shell scripts (for Arch Linux, this is resume mkinitcpio hook), so I feel that this feature has its place within systemd. Due to the nature of hibernation, the resume unit must be activated before any modifications to filesystems take place. This can happen only in initramfs before mounting anything. So, first patch orders all non-root fsck after local-fs-pre.target, which in turn allows to order the resume unit before those fsck instances. Second and third patches add the tool, the unit and the generator. There are some issues with this implementation. - legacy usr.mount is not automatically ordered after local-fs-pre.target, so systemd-resume@.service has to be manually ordered before it; Not following here. We do not really support /usr split out unless it is already mounted in the initrd. But in the initrd its called sysroot-usr.mount... To me this doesn't look like something to do here? - systemd-udevd.service, which is needed for creating persistent block device symlinks, is transitively ordered after systemd-remount-fs.service via at least systemd-udev-hwdb-update.service and systemd-sysusers.service. Hence, if these units are present, an ordering cycle happens and resume is impossible. Hmm? What's the cycle precisely? Not following? 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] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
On Monday 25 August 2014 at 19:42:21, Lennart Poettering wrote: On Mon, 25.08.14 02:16, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. It adds: - a 'systemd-resume' tool which takes path to a device node and writes its major:minor to /sys/power/state; - a corresponding 'systemd-resume@.service' templated unit; - a 'systemd-resume-generator' generator which parses the kernel command line and instantiates the unit as necessary. This functionality already exists in-kernel, but only for /dev/sdXY-style pathes. Implementing it in userspace allows to use arbitrary udev-created symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar). Userspace parsing of resume= kernel command line parameter has been traditionally done in initramfs via shell scripts (for Arch Linux, this is resume mkinitcpio hook), so I feel that this feature has its place within systemd. Due to the nature of hibernation, the resume unit must be activated before any modifications to filesystems take place. This can happen only in initramfs before mounting anything. So, first patch orders all non-root fsck after local-fs-pre.target, which in turn allows to order the resume unit before those fsck instances. Second and third patches add the tool, the unit and the generator. There are some issues with this implementation. - legacy usr.mount is not automatically ordered after local-fs-pre.target, so systemd-resume@.service has to be manually ordered before it; Not following here. We do not really support /usr split out unless it is already mounted in the initrd. But in the initrd its called sysroot-usr.mount... To me this doesn't look like something to do here? Theoretically it is possible to have initramfs's /usr split out. I know that it sounds crazy, but if someone will do this, they will lose their data if usr.mount not properly handled. - systemd-udevd.service, which is needed for creating persistent block device symlinks, is transitively ordered after systemd-remount-fs.service via at least systemd-udev-hwdb-update.service and systemd-sysusers.service. Hence, if these units are present, an ordering cycle happens and resume is impossible. Hmm? What's the cycle precisely? Not following? systemd-remount.fs.service - systemd-udev-hwdb-update.service - systemd-udevd.service systemd-sysusers.service Here, the arrow represents an After= dependency. If either systemd-udev-hwdb-update.service or systemd-sysusers.service becomes part of the transaction (== becomes included in the initramfs), it becomes impossible for systemd-resume@.service to start after systemd-udevd.service. The outcome can vary: - a 90 second wait for dev-disk-by\x2dfoo-bar.device and dependency failure (if After=systemd-udevd.service has not been specified); - an ordering cycle and removal of systemd-resume@.service from transaction (if After=systemd-udevd.service has been specified, just as it is now). Both situations are very unlikely (who would add usr.mount to initramfs? who would add systemd-sysusers.service to initramfs?), but nevertheless possible. -- 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] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
On Mon, 25.08.14 21:52, Ivan Shapovalov (intelfx...@gmail.com) wrote: - legacy usr.mount is not automatically ordered after local-fs-pre.target, so systemd-resume@.service has to be manually ordered before it; Not following here. We do not really support /usr split out unless it is already mounted in the initrd. But in the initrd its called sysroot-usr.mount... To me this doesn't look like something to do here? Theoretically it is possible to have initramfs's /usr split out. I know that it sounds crazy, but if someone will do this, they will lose their data if usr.mount not properly handled. initrd cannot have their data split out. I am completely happy about breaking this, should it exist (which I doubt). If either systemd-udev-hwdb-update.service or systemd-sysusers.service becomes part of the transaction (== becomes included in the initramfs), it becomes impossible for systemd-resume@.service to start after systemd-udevd.service. The outcome can vary: - a 90 second wait for dev-disk-by\x2dfoo-bar.device and dependency failure (if After=systemd-udevd.service has not been specified); - an ordering cycle and removal of systemd-resume@.service from transaction (if After=systemd-udevd.service has been specified, just as it is now). Both situations are very unlikely (who would add usr.mount to initramfs? who would add systemd-sysusers.service to initramfs?), but nevertheless possible. Hmm, let me see, so you are basically saying that udev wants to run after sysusers, and sysusers shall run after the file systems are mounted, and that systemd-resume@.service wants to run before that, but needs to wait until the devices have popped up, which they won't until udev is started? So, I am pretty sure we don#t want an explicit After= order here between dbus and systemd-resume@.service... Hmm, but yuck, I don't see a nice way to fix this for good. Grrr. I'd probably just merge this as is, and let people who are crazy enough to run sysuers or hwdb-update in the initrd, to figure this out. Let's just wait until this pops 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] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
On Monday 25 August 2014 at 20:07:28, Lennart Poettering wrote: On Mon, 25.08.14 21:52, Ivan Shapovalov (intelfx...@gmail.com) wrote: - legacy usr.mount is not automatically ordered after local-fs-pre.target, so systemd-resume@.service has to be manually ordered before it; Not following here. We do not really support /usr split out unless it is already mounted in the initrd. But in the initrd its called sysroot-usr.mount... To me this doesn't look like something to do here? Theoretically it is possible to have initramfs's /usr split out. I know that it sounds crazy, but if someone will do this, they will lose their data if usr.mount not properly handled. initrd cannot have their data split out. I am completely happy about breaking this, should it exist (which I doubt). OK. Removed Before=usr.mount for v4. If either systemd-udev-hwdb-update.service or systemd-sysusers.service becomes part of the transaction (== becomes included in the initramfs), it becomes impossible for systemd-resume@.service to start after systemd-udevd.service. The outcome can vary: - a 90 second wait for dev-disk-by\x2dfoo-bar.device and dependency failure (if After=systemd-udevd.service has not been specified); - an ordering cycle and removal of systemd-resume@.service from transaction (if After=systemd-udevd.service has been specified, just as it is now). Both situations are very unlikely (who would add usr.mount to initramfs? who would add systemd-sysusers.service to initramfs?), but nevertheless possible. Hmm, let me see, so you are basically saying that udev wants to run after sysusers, and sysusers shall run after the file systems are mounted, and that systemd-resume@.service wants to run before that, but needs to wait until the devices have popped up, which they won't until udev is started? Yes, I've meant exactly this. So, I am pretty sure we don#t want an explicit After= order here between dbus and systemd-resume@.service... Hmm, but yuck, I don't see a nice way to fix this for good. Grrr. I'd probably just merge this as is, and let people who are crazy enough to run sysuers or hwdb-update in the initrd, to figure this out. Let's just wait until this pops up... Lennart So, do you want me to leave After=systemd-udevd.service or remove it? (An ordering cycle or a waiting timeout?) -- 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] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
On Mon, 25.08.14 22:23, Ivan Shapovalov (intelfx...@gmail.com) wrote: So, I am pretty sure we don#t want an explicit After= order here between dbus and systemd-resume@.service... Hmm, but yuck, I don't see a nice way to fix this for good. Grrr. I'd probably just merge this as is, and let people who are crazy enough to run sysuers or hwdb-update in the initrd, to figure this out. Let's just wait until this pops up... Lennart So, do you want me to leave After=systemd-udevd.service or remove it? (An ordering cycle or a waiting timeout?) Remove it. There's no improvement if you have it, and we don't do it in other cases that are remotely similar to this: services depend on the devices they manage, but never on the device manager itself. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. It adds: - a 'systemd-resume' tool which takes path to a device node and writes its major:minor to /sys/power/state; - a corresponding 'systemd-resume@.service' templated unit; - a 'systemd-resume-generator' generator which parses the kernel command line and instantiates the unit as necessary. This functionality already exists in-kernel, but only for /dev/sdXY-style pathes. Implementing it in userspace allows to use arbitrary udev-created symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar). Userspace parsing of resume= kernel command line parameter has been traditionally done in initramfs via shell scripts (for Arch Linux, this is resume mkinitcpio hook), so I feel that this feature has its place within systemd. Due to the nature of hibernation, the resume unit must be activated before any modifications to filesystems take place. This can happen only in initramfs before mounting anything. So, first patch orders all non-root fsck after local-fs-pre.target, which in turn allows to order the resume unit before those fsck instances. Second and third patches add the tool, the unit and the generator. There are some issues with this implementation. - legacy usr.mount is not automatically ordered after local-fs-pre.target, so systemd-resume@.service has to be manually ordered before it; - systemd-udevd.service, which is needed for creating persistent block device symlinks, is transitively ordered after systemd-remount-fs.service via at least systemd-udev-hwdb-update.service and systemd-sysusers.service. Hence, if these units are present, an ordering cycle happens and resume is impossible. Encountering these conditions is very unlikely inside of an initramfs (who would make the in-initramfs /usr external? who would add systemd-sysusers into initramfs?), but there can still be pathological cases. So, I would like someone to comment on these issues. Thanks for reviewing! v2: fix issues pointed out by Andrei: - don't RemainAfterExit because it's useless - don't attempt to resume outside of initramfs because it's unsafe (reiserfs replays journal even if mounted RO) v3: fix mistakes spotted by Thomas: - return 0 in main path of resume.c:process_resume() - fix type and add missing cleanup attribute in resume-generator.c:main() Ivan Shapovalov (3): units: order systemd-fsck@.service after local-fs-pre.target. resume: add a tool to write a device node's major:minor to /sys/power/resume. resume-generator: add a generator for instantiating the resume unit. Makefile-man.am | 9 Makefile.am | 28 -- man/kernel-command-line.xml | 13 - man/systemd-resume-generator.xml| 91 +++ man/systemd-res...@.service.xml | 81 src/resume-generator/Makefile | 1 + src/resume-generator/resume-generator.c | 95 + src/resume/Makefile | 1 + src/resume/resume.c | 83 units/systemd-f...@.service.in | 2 +- units/systemd-res...@.service.in| 20 +++ 11 files changed, 418 insertions(+), 6 deletions(-) create mode 100644 man/systemd-resume-generator.xml create mode 100644 man/systemd-res...@.service.xml create mode 12 src/resume-generator/Makefile create mode 100644 src/resume-generator/resume-generator.c create mode 12 src/resume/Makefile create mode 100644 src/resume/resume.c create mode 100644 units/systemd-res...@.service.in -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
