Bug 57793 - Please add the ability to go into standby mode to systemd-sleep.
Summary: Please add the ability to go into standby mode to systemd-sleep.
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: low enhancement
Assignee: Zbigniew Jedrzejewski-Szmek
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-02 01:33 UTC by gooberslot
Modified: 2013-05-06 22:45 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
prep patch (2.06 KB, patch)
2013-03-17 23:58 UTC, Zbigniew Jedrzejewski-Szmek
Details | Splinter Review
add --action=freeze,standby,etc to systemd-sleep (18.08 KB, patch)
2013-03-18 00:00 UTC, Zbigniew Jedrzejewski-Szmek
Details | Splinter Review
Proposed patch (11.20 KB, patch)
2013-04-18 15:26 UTC, Harald Hoyer
Details | Splinter Review

Description gooberslot 2012-12-02 01:33:37 UTC
From what I can tell systemd-sleep only supports Suspend-to-ram, hibernate and hybrid mode, it would be nice if it also supported old fashioned standby mode too.
Comment 1 Lennart Poettering 2012-12-02 15:29:32 UTC
Uh? What is the supposed difference between suspend-to-ram and "good old standby" in your opinion?

There's only suspend-to-disk (aka hibernate), suspend-to-ram (aka suspend), suspend-to-both (aka hybernate-sleep), really.
Comment 2 gooberslot 2012-12-11 05:47:38 UTC
My computer can't support STR without losing its overclocked settings, so standby is the best I can do. It only saves about 1/3 to half power but it's better than nothing.
Comment 3 Lennart Poettering 2012-12-19 21:46:35 UTC
Uh, I am not sure what you are looking for, but STR and STD are the only things the kernel knows about. There is no such thing as "suspend" that was different from STR.

So, what precisely are you requesting?
Comment 4 gooberslot 2012-12-21 12:12:02 UTC
Doing "echo -n "standby" > /sys/power/state" seems to work for me. Also, if I cat /sys/power/state it shows "standby disk". pm-suspend from pm-utils also works. I probably should have stated from the beginning that I'm using Arch so maybe they do something different to their kernel.

For now, I've edited the systemd-suspend.service to simply call pm-suspend as a workaround.
Comment 5 Mantas Mikulėnas 2013-01-15 00:06:42 UTC
(In reply to comment #3)
> Uh, I am not sure what you are looking for, but STR and STD are the only
> things the kernel knows about. There is no such thing as "suspend" that was
> different from STR.

kernel/power/main.c:280 recognizes 'standby' as a separate state.

'mem' is "Suspend-to-RAM" (ACPI S3) and 'standby' is "Power-On Suspend" (ACPI S1 if I remember correctly), a lighter state that keeps some hardware powered on. Which states are supported seems to depend on the hardware.

I don't think a new systemctl command would be necessary – just add a config option to select whether "systemctl suspend" means 'mem' or 'standby', to cover all systems with broken 'mem'.
Comment 6 Zbigniew Jedrzejewski-Szmek 2013-02-02 16:10:26 UTC
Note: some machines have all three (standby mem disk), so automatically guessing which one to pick is not possible.

> I don't think a new systemctl command would be necessary – just add a config
> option to select whether "systemctl suspend" means 'mem' or 'standby', to
> cover all systems with broken 'mem'.
I'd go for a separate verb 'standby'. If the kernel exposes it, we want to too. And since the list is hardcoded to those three options in the kernel, it doesn't look new suspend types will be added, so adding a new verb will be cleanest/easiest to use.
Comment 7 Kay Sievers 2013-02-03 16:54:45 UTC
(In reply to comment #6)
> If the kernel exposes it, we want to too.

There is absolutely no rule like that, often it is quite the opposite.
There are many things which aren't "clean" in the kernel interfaces, and
we should be very careful with such generalizations. :)

In many cases userspace has more information than the kernel, has policy, configuration it can use, so it can be smarter than the kernel knobs, and
we should really try that, if possible. 

> so adding a new verb will be cleanest/easiest to use.

I don't really think so.

It's a rather exotic use, and mainly to work around broken hardware and
kernel setups. If needed, we could make it overridable by custom config,
which of the kernel facilities to chose to suspend, but we should really
not explode the verbs which tools, using the systemd interfaces will need
to support.
Comment 8 Lennart Poettering 2013-02-04 09:02:37 UTC
I think we should avoid introducing high-level verbs for all possible kernel power management states. Instead it might be useful to allow changing what the existing verbs mean.

Already now we don't expose the kernel's vocabulary 1:1 in systemd. We use "hibernate" for what the kernel calls "suspend" and "disk" at some places, and "suspend" for what the kernel calls "sleep" and "mem".

I'd thus suggest we simply define some rough semantics for the existing three verbs, but leave it to the specific system to actually bind them to whatever the underlying hardware might support. Maybe some definitions like the following:

 suspend = a low-power state where execution of the OS is paused, and complete power loss might result in lost data, and which is fast to enter and exit

 hibernate = a low-power state where execution of the OS is paused, and complete power loss does not result in lost data, and which might be slow to enter and exit

 hybrid-sleep = a low-power state where execution of the OS is paused, which might be slow to enter, and on complete power loss does not result in lost data but might be slower to exit in that case.

These rough definitions would then allow implementations to implement the verbs with different logic behind, possibly even implementing some of them with the exact same result (for example, hybrid sleep is a "superset" of hibernate, and hence any implementation for hybrid-sleep might be suitable for hibernate too.)

Now, coming back to the actual request this bug is about: with this scheme in place we could then enable users, admins or system builders to override the default logic systemd uses, for example to change "suspend" from meaning "mem" to "standby", and this would be perfectly within the definitions above. 

The question would then only be where to configure what the "systemd-sleep" binary actually writes into /sys/power/kernel. Instead of introducing a new configuration file a simple approach could be to add support for a new command line argument to "systemd-sleep" to cover the "standby" case, and then ask the admin to copy /usr/lib/systemd/system/systemd-sleep.service to /etc/systemd/system/systemd-sleep.service and edit it there to append the argument.

This solution makes the mapping of the high-level verbs to the low-level implementations a configuration option. One couldn't enter the low-level operations without changing configuration. I personally don't see that as much of a problem though. 

If we go this way we probably should set up a wiki page describing what the user/admin/system integration needs to do to change the meanings of suspend/hibernate/hybrid-sleep.
Comment 9 Lennart Poettering 2013-02-04 21:15:47 UTC
Opinions on the approach I suggested?

(Also, while we are at it, we probably should solve  https://bugzilla.freedesktop.org/show_bug.cgi?id=57882 the same way as this issue)
Comment 10 Zbigniew Jedrzejewski-Szmek 2013-02-08 00:51:10 UTC
Outlined approach seems fine.
I'd go for --state=mem|disk|<custom>, --action=platform|shutdown|reboot|suspend|<custom>.

One question: do we want to detect what /sys/power/state supports and automatically use the best option? I'd say yes, unless --state is used.
Comment 11 Lennart Poettering 2013-02-08 00:55:54 UTC
(In reply to comment #10)
> Outlined approach seems fine.
> I'd go for --state=mem|disk|<custom>,
> --action=platform|shutdown|reboot|suspend|<custom>.
> 
> One question: do we want to detect what /sys/power/state supports and
> automatically use the best option? I'd say yes, unless --state is used.

Yeah, probably, to the degree where that makes sense. Defaulting to "mem" with a fallback "standby" if that exists definitely makes a ton of sense to me.
Comment 13 Zbigniew Jedrzejewski-Szmek 2013-03-17 23:58:45 UTC
Created attachment 76667 [details] [review]
prep patch
Comment 14 Zbigniew Jedrzejewski-Szmek 2013-03-18 00:00:07 UTC
Created attachment 76668 [details] [review]
add --action=freeze,standby,etc to systemd-sleep

Here's a patch (two actually, the first one is prep), which allows freeze and standby to be used. I'm not terribly happy with the way it works because modyfing a unit file is a relatively complex thing for the administrator, and thus making the change requires 3 lines of code:
# /etc/systemd/system/systemd-suspend.service.d/suspend.conf
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-sleep --action=freeze suspend

But OTOH, changing the suspend mode is a relatively uncommon request, so maybe it's OK.
Comment 15 Lennart Poettering 2013-03-18 13:00:48 UTC
(In reply to comment #14)
> Created attachment 76668 [details] [review] [review]
> add --action=freeze,standby,etc to systemd-sleep
> 
> Here's a patch (two actually, the first one is prep), which allows freeze
> and standby to be used. I'm not terribly happy with the way it works because
> modyfing a unit file is a relatively complex thing for the administrator,
> and thus making the change requires 3 lines of code:
> # /etc/systemd/system/systemd-suspend.service.d/suspend.conf
> [Service]
> ExecStart=
> ExecStart=/usr/lib/systemd/systemd-sleep --action=freeze suspend
> 
> But OTOH, changing the suspend mode is a relatively uncommon request, so
> maybe it's OK.

Hmm, I'd prefer if --action= would simply pull the selected actions to the front instead of just dropping all others? Note that we have to update logind's CanSuspend() code to look for the other verbs too, and it would be good if we wouldn't have to make that code configurable too. Hence: Make CanSuspend() (and friends) simply return true if *any* suspend/freeze/standby verb is available, but then allow the user via --action to choose which ones is preferredly used.

And yupp, I think making this configurable via copying a unit file sounds good enough to me. This should be an exotic setting, and not a common one, and hence a clean but possibly somewhat obscure way to configure this sounds perfect to me.
Comment 16 Zbigniew Jedrzejewski-Szmek 2013-03-18 14:20:31 UTC
[It seem that my reply via mail got lost, reposting through the web interface.]
                               
On Mon, Mar 18, 2013 at 01:00:48PM +0000, bugzilla-daemon@freedesktop.org wrote:                                    
> --- Comment #15 from Lennart Poettering <lennart@poettering.net> ---
> Hmm, I'd prefer if --action= would simply pull the selected actions to the
> front instead of just dropping all others?
People might use it in cases when e.g. 'mem' hangs, but 'freeze'
works. So if they took the pains to configure something, let's just
use whatever they specified. The switch already accepts multiple options in
order of preference.

> Note that we have to update logind's
> CanSuspend() code to look for the other verbs too, and it would be good if we
Oh, I missed that. Making CanSuspend() smart enough to look only at configured
verbs is not really an option, unless the configuration was done in a different
way. Making CanSuspend() only look at configured verbs would be a good reason
to move the configuration to e.g. /etc/systemd/system.conf and read it from
there in both programs.

> wouldn't have to make that code configurable too. Hence: Make CanSuspend() (and
> friends) simply return true if *any* suspend/freeze/standby verb is available,
> but then allow the user via --action to choose which ones is preferredly used.
I don't know, see above.

> And yupp, I think making this configurable via copying a unit file sounds good
> enough to me. This should be an exotic setting, and not a common one, and hence
> a clean but possibly somewhat obscure way to configure this sounds perfect to
> me.
Comment 17 Zbigniew Jedrzejewski-Szmek 2013-03-18 14:26:44 UTC
When testing 'freeze', about half of the times my notebook would power off after returning from freeze. This is because the only way to wake up from freeze is to tap the power button. In normal 'mem' suspend, I can use any key on the keyboard, but with 'freeze' they don't work. Also, when using 'mem', the power-button event does not cause any further action apart waking from sleep. Under 'freeze', after pressing 'power' shortly, I would see gnome restored, and windows repainted, and after that the normal shutdown procedure would begin. I suppose that this is a kernel bug to some extent, but 3.9-rc2 is so flaky, that I prefer not to draw strong conclusions. It might be even two bugs: one that 'freeze' does not swallow the power-button event, and two, that sometimes it gets lost.
Comment 18 Zbigniew Jedrzejewski-Szmek 2013-03-18 14:27:51 UTC
On Mon, Mar 18, 2013 at 01:00:48PM +0000, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #15 from Lennart Poettering <lennart@poettering.net> ---
> Hmm, I'd prefer if --action= would simply pull the selected actions to the
> front instead of just dropping all others?
People might use it in cases when e.g. 'mem' hangs, but 'freeze'
works. So if they took the pains to configure something, let's just
use whatever they specified. The switch already accepts multiple options in
order of preference.

> Note that we have to update logind's
> CanSuspend() code to look for the other verbs too, and it would be good if we
Oh, I missed that. Making CanSuspend() smart enough to look only at configured
verbs is not really an option, unless the configuration was done in a different
way. Making CanSuspend() only look at configured verbs would be a good reason
to move the configuration to e.g. /etc/systemd/system.conf and read it from
there in both programs.

> wouldn't have to make that code configurable too. Hence: Make CanSuspend() (and
> friends) simply return true if *any* suspend/freeze/standby verb is available,
> but then allow the user via --action to choose which ones is preferredly used.
I don't know, see above.

> And yupp, I think making this configurable via copying a unit file sounds good
> enough to me. This should be an exotic setting, and not a common one, and hence
> a clean but possibly somewhat obscure way to configure this sounds perfect to
> me.
Comment 19 Harald Hoyer 2013-04-18 15:26:33 UTC
Created attachment 78185 [details] [review]
Proposed patch

this is quickly hacked together version, without knowing other patches exist
Comment 20 Kay Sievers 2013-04-18 15:48:07 UTC
We don't want more verbs:
  http://lists.freedesktop.org/archives/systemd-devel/2013-March/009242.html
Comment 21 Zbigniew Jedrzejewski-Szmek 2013-05-06 22:45:58 UTC
Fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=19adb8a320.


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.