[systemd-devel] Implementing resume from hibernation as a systemd unit file

Ivan Shapovalov intelfx100 at gmail.com
Fri Aug 15 02:02:24 PDT 2014

On Thursday 14 August 2014 at 12:56:10, Lennart Poettering wrote:	
> On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx100 at 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...

Ivan Shapovalov / intelfx /

> That's pretty much exactly how the got auto root thing works...
> Lennart
-------------- 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/20140815/bf04168f/attachment.sig>

More information about the systemd-devel mailing list