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

Andrei Borzenkov arvidjaar at gmail.com
Sat Aug 23 07:22:42 PDT 2014


В Sat, 23 Aug 2014 16:47:51 +0400
Ivan Shapovalov <intelfx100 at gmail.com> пишет:

> 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
> 1) in initramfs before mounting anything, and
> 2) without initramfs before remounting rootfs read-write (provided that it is
>    mounted RO initially).
> 

Your patch has

+ConditionPathExists=|/etc/initrd-release

Which excludes non-initrd usage, right? Also some filesystems (reiserfs
comes in mind) replayed journal even when mounted read-only. So may be
it should explicitly state initrd-only support and name units
accordingly.

> 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;
> - 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 (at least initramfs-less case), an ordering
>   cycle happens and resume is impossible.
> 
> So, I would like someone to comment on these.
> 
> This is my first patch to this project, so feel free to flak me for missing
> something obvious :)
> 
> Thanks for reviewing!
> 
> Ivan Shapovalov (3):
>   units: order systemd-fsck at .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-resume at .service.xml         | 81 +++++++++++++++++++++++++++++
>  src/resume-generator/Makefile           |  1 +
>  src/resume-generator/resume-generator.c | 89 ++++++++++++++++++++++++++++++++
>  src/resume/Makefile                     |  1 +
>  src/resume/resume.c                     | 82 +++++++++++++++++++++++++++++
>  units/systemd-fsck at .service.in          |  2 +-
>  units/systemd-resume at .service.in        | 23 +++++++++
>  11 files changed, 414 insertions(+), 6 deletions(-)
>  create mode 100644 man/systemd-resume-generator.xml
>  create mode 100644 man/systemd-resume at .service.xml
>  create mode 120000 src/resume-generator/Makefile
>  create mode 100644 src/resume-generator/resume-generator.c
>  create mode 120000 src/resume/Makefile
>  create mode 100644 src/resume/resume.c
>  create mode 100644 units/systemd-resume at .service.in
> 



More information about the systemd-devel mailing list