2014-08-27 00:17:44 +04:00
<?xml version="1.0"?>
<!-- * - nxml - * -->
2019-03-14 16:40:58 +03:00
< !DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
2023-12-25 17:48:33 +03:00
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
2020-11-09 07:23:58 +03:00
<!-- SPDX - License - Identifier: LGPL - 2.1 - or - later -->
2023-04-18 20:21:55 +03:00
<refentry id= "systemd-hibernate-resume.service" conditional= 'ENABLE_HIBERNATE' >
2014-08-27 00:17:44 +04:00
2015-02-04 05:14:13 +03:00
<refentryinfo >
2023-04-18 20:21:55 +03:00
<title > systemd-hibernate-resume.service</title>
2015-02-04 05:14:13 +03:00
<productname > systemd</productname>
</refentryinfo>
2014-08-27 00:17:44 +04:00
2015-02-04 05:14:13 +03:00
<refmeta >
2023-04-18 20:21:55 +03:00
<refentrytitle > systemd-hibernate-resume.service</refentrytitle>
2015-02-04 05:14:13 +03:00
<manvolnum > 8</manvolnum>
</refmeta>
2014-08-27 00:17:44 +04:00
2015-02-04 05:14:13 +03:00
<refnamediv >
2023-04-18 20:21:55 +03:00
<refname > systemd-hibernate-resume.service</refname>
units: introduce systemd-hibernate-clear.service that clears
stale HibernateLocation EFI variable
Currently, if the HibernateLocation EFI variable exists,
but we failed to resume from it, the boot carries on
without clearing the stale variable. Therefore, the subsequent
boots would still be waiting for the device timeout,
unless the variable is purged manually.
There's no point to keep trying to resume after a successful
switch-root, because the hibernation image state
would have been invalidated by then. OTOH, we don't
want to clear the variable prematurely either,
i.e. in initrd, since if the resume device is the same
as root one, the boot won't succeed and the user might
be able to try resuming again. So, let's introduce a
unit that only runs after switch-root and clears the var.
Fixes #32021
2024-03-31 15:52:39 +03:00
<refname > systemd-hibernate-clear.service</refname>
2015-02-04 05:14:13 +03:00
<refname > systemd-hibernate-resume</refname>
<refpurpose > Resume from hibernation</refpurpose>
</refnamediv>
2014-08-27 00:17:44 +04:00
2015-02-04 05:14:13 +03:00
<refsynopsisdiv >
2023-04-18 20:21:55 +03:00
<para > <filename > systemd-hibernate-resume.service</filename> </para>
units: introduce systemd-hibernate-clear.service that clears
stale HibernateLocation EFI variable
Currently, if the HibernateLocation EFI variable exists,
but we failed to resume from it, the boot carries on
without clearing the stale variable. Therefore, the subsequent
boots would still be waiting for the device timeout,
unless the variable is purged manually.
There's no point to keep trying to resume after a successful
switch-root, because the hibernation image state
would have been invalidated by then. OTOH, we don't
want to clear the variable prematurely either,
i.e. in initrd, since if the resume device is the same
as root one, the boot won't succeed and the user might
be able to try resuming again. So, let's introduce a
unit that only runs after switch-root and clears the var.
Fixes #32021
2024-03-31 15:52:39 +03:00
<para > <filename > systemd-hibernate-clear.service</filename> </para>
2015-06-18 20:47:44 +03:00
<para > <filename > /usr/lib/systemd/systemd-hibernate-resume</filename> </para>
2015-02-04 05:14:13 +03:00
</refsynopsisdiv>
2014-08-27 00:17:44 +04:00
2015-02-04 05:14:13 +03:00
<refsect1 >
<title > Description</title>
2014-08-27 00:17:44 +04:00
2023-04-18 20:21:55 +03:00
<para > <filename > systemd-hibernate-resume.service</filename> initiates the resume from hibernation.</para>
2014-08-27 00:17:44 +04:00
2023-11-06 16:59:00 +03:00
<para > <command > systemd-hibernate-resume</command> only supports the in-kernel hibernation
2023-04-18 20:21:55 +03:00
implementation, see <ulink url= "https://docs.kernel.org/power/swsusp.html" > Swap suspend</ulink> .
2024-03-10 17:44:02 +03:00
Internally, it works by writing the major:minor of selected device node to
2023-04-18 20:21:55 +03:00
<filename > /sys/power/resume</filename> , along with the offset in memory pages
(<filename > /sys/power/resume_offset</filename> ) if supported.</para>
2014-08-27 00:17:44 +04:00
units: introduce systemd-hibernate-clear.service that clears
stale HibernateLocation EFI variable
Currently, if the HibernateLocation EFI variable exists,
but we failed to resume from it, the boot carries on
without clearing the stale variable. Therefore, the subsequent
boots would still be waiting for the device timeout,
unless the variable is purged manually.
There's no point to keep trying to resume after a successful
switch-root, because the hibernation image state
would have been invalidated by then. OTOH, we don't
want to clear the variable prematurely either,
i.e. in initrd, since if the resume device is the same
as root one, the boot won't succeed and the user might
be able to try resuming again. So, let's introduce a
unit that only runs after switch-root and clears the var.
Fixes #32021
2024-03-31 15:52:39 +03:00
<para > The resume device node is either passed directly through arguments, or automatically acquired
from kernel command line options and/or <varname > HibernateLocation</varname> EFI variable. The latter
will normally be cleared by <filename > systemd-hibernate-resume.service</filename> on resumption.
If a stale variable is detected, it would be cleared by
<filename > systemd-hibernate-clear.service</filename> .</para>
2023-04-18 20:21:55 +03:00
<para > Failing to initiate a resume is not an error condition. It may mean that there was
no resume image (e. g. if the system has been simply powered off and not hibernated).
In such cases, the boot is ordinarily continued.</para>
2015-02-04 05:14:13 +03:00
</refsect1>
2014-08-27 00:17:44 +04:00
2015-02-04 05:14:13 +03:00
<refsect1 >
<title > See Also</title>
2023-12-22 21:09:32 +03:00
<para > <simplelist type= "inline" >
<member > <citerefentry > <refentrytitle > systemd</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> </member>
<member > <citerefentry > <refentrytitle > systemd-hibernate-resume-generator</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry> </member>
</simplelist> </para>
2015-02-04 05:14:13 +03:00
</refsect1>
2014-08-27 00:17:44 +04:00
</refentry>