Bug 57793

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.

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.

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?

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.

(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'.

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.

(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.

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.

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)

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.

(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.

And I guess the new "freeze" mode as brought up should be covered by the same scheme:

https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7e73c5ae6e7991a6c01f6d096ff8afaef4458c36

http://lists.freedesktop.org/archives/systemd-devel/2013-February/009238.html

Created attachment 76667 [details] [review]
prep patch

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.

(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.

[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.

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.

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.

Created attachment 78185 [details] [review]
Proposed patch

this is quickly hacked together version, without knowing other patches exist

We don't want more verbs:
  http://lists.freedesktop.org/archives/systemd-devel/2013-March/009242.html

Fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=19adb8a320.