[systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Monday 25 August 2014 at 19:42:21, Lennart Poettering wrote:	
> On Mon, 25.08.14 02:16, Ivan Shapovalov (intelfx100 at 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 at .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 at .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 at .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 at .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 /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140825/39f52fc4/attachment.sig>