Bug 58679 - systemd overriding /sys/power/disk with "platform" on hibernate
Summary: systemd overriding /sys/power/disk with "platform" on hibernate
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
Depends on:
Reported: 2012-12-23 12:07 UTC by tekrotzen
Modified: 2013-01-14 22:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description tekrotzen 2012-12-23 12:07:50 UTC
My computer restarts automatically if /sys/power/disk is set to platform.

I used to echo "shutdown" in it, but since systemd 196 (I suppose), this setting is overrided in sleep/sleep.c:

        if (streq(argv[1], "hibernate")) {
                if (write_one_line_file("/sys/power/disk", "platform") < 0)
                        write_one_line_file("/sys/power/disk", "shutdown");

Is there any clean way to change this behaviour?
As far as I understand hooks are innefectives, as they are called before.

Comment 1 tekrotzen 2012-12-23 12:22:25 UTC
at the moment I created a copy of systemd-hibernate.service in /etc/systemd/system/ , replacing

ExecStart=/usr/lib/systemd/systemd-sleep hibernate

with a small script:

echo -n "shutdown" > /sys/power/disk
echo -n "disk" > /sys/power/state
Comment 2 Lennart Poettering 2012-12-24 11:41:45 UTC
This really sounds as if this should be fixed in the kernel. i.e. if "platform" doesn't work correctly on your system the kernel should have a DMI check and execute a normal shutdown instead. Working around that in userspace is not how we do these things these days.
Comment 3 tekrotzen 2012-12-24 13:33:17 UTC
I guess you're right.
I don't know what is visible with a DMI check, and saw the following in the kernel docs, so I thought I was maybe not alone... ;)

http://www.kernel.org/doc/Documentation/power/swsusp.txt :

You need to append resume=/dev/your_swap_partition to kernel command
line. Then you suspend by

echo shutdown > /sys/power/disk; echo disk > /sys/power/state

. If you feel ACPI works pretty well on your system, you might try

echo platform > /sys/power/disk; echo disk > /sys/power/state

Reason I filled this bug.

But I do completely understand your point.

I was just wondering: as some people seem to use other options, as "reboot" (see attached bug), maybe a solution could be to grep /sys/power/disk for the selected option and to use that instead of "platform"?

This way "platform" would still be used if it is the system default, but if for any reason a user wants to use something else instead it wouldn't be overwritten:
This could be a cheap way to allow testing and customisation...

Not sure if I'm missing something obvious, in this case please accept my appologies...

And thanks for the quick feedback, in any case!
Comment 4 bugzilla 2012-12-25 15:27:28 UTC
Tekrotzen's replacement script works fine for me too, adapted to do either 'reboot' or 'platform' as required (see my bug report 57882).

The only drawback is that it doesn't appear to run the sleep hooks in /usr/lib/systemd/system-sleep/ - no doubt these could be added to the script instead.

The bug definitely appeared at version 196, perhaps as a result of the changes for 'hybrid sleep' - reverting back to 195 results in the problem going away.

Hopefully the developers will produce a fix in due course. Using a workaround is not ideal.

Comment 5 Lennart Poettering 2013-01-14 22:39:19 UTC
We won't work around kernel bugs from userspace really. Fix problems where they are. If it is known that some firmware cannot handle "platform" in /sys/power/disk, then this option should be removed from the settings on that system, but that needs to happen in the kernel, not worked around in userspace.

Or in other words: essential quirks like this (i.e. which if not applied will cause fatal issues) need to be applied in the kernel, not in userspace.

hence closing, please file bug on the kernel bugzilla, possibly referring to this bug.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.