FFe: Support suspend-then-hibernate

Bug #1756006 reported by Mario Limonciello on 2018-03-15
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
Wishlist
Unassigned
Bionic
Low
Unassigned
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

Suspend to hibernate is a new feature that will put the system into hibernate after a period of time spent in the system's supported sleep state. This mode will be used on some systems that take suspend to idle in the future with Ubuntu 18.04.

This feature is available in upstream systemd from these two commits.
https://github.com/systemd/systemd/commit/c58493c00af97146d3b6c24da9c0371978124703
https://github.com/systemd/systemd/commit/9aa2e409bcb70f3952b38a35f16fc080c22dd5a5
This is accepted upstream.

The policy needs to be made available to gnome from this commit:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/9
As of 3/15/2018 this is not yet accepted or rejected.

The new mode is not selected by default, but that can be changed from a separate policy package.
The policy for the amount of time spent in S3/S2I can be configured by a separate package.

Kai-Heng Feng (kaihengfeng) wrote :

Out of curiosity - do we have firmware-based hibernate [1] enabled out of the box?

[1] https://mjg59.dreamwidth.org/26022.html

Mario Limonciello (superm1) wrote :

No, not on modern system. We haven't used that technology for a while.

Jeremy Bicha (jbicha) on 2018-03-25
tags: added: bionic rls-bb-incoming
Dimitri John Ledkov (xnox) wrote :

From systemd point of view, the patches are relatively straight forward, and simply add "one more way to sleep/suspend/hybernate/etc" without affecting any other code paths or any other functionality. Thus i see little risk for landing the systemd patches.

If this turns out to be bad, only the policy would need to be change to either not offer it by default, or not use by default. Or some such.

Łukasz Zemczak (sil2100) wrote :

I am generally fine with this feature, especially after Dimitri's input. So formally I approve of this FFe. But since this will also be changing user-visible strings in systemd, I *think* you will also need to have an UIFe, e.g. you will have to inform the doc and translation teams [1]. I'm not sure about this as I have no idea how systemd translations are driven as they do not seem to be handled through launchpad. It might be that both the documentation and translation teams do not provide any translation support for these packages per-se and no formal UIFe will be required.

Anyway, FFe approved but please, just in case, reach out to the required teams to get a better understanding if any other exceptions need to be considered.

[1] https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions

Łukasz Zemczak (sil2100) wrote :

Actually, I guess an UIFe will anyway be required as for the gnome-settings-manager? I can't reach the Gnome gitlab today so I don't know for sure. If it does affect some user visible strings, please proceed as per my earlier comment and if the respective teams go +1 on it, we'll formally switch this bug to 'Triaged'.

Sebastien Bacher (seb128) wrote :

(rls-bb-notfixing from a desktop perspective, it doesn't need to be milestoned but we want to review/comment on the change anyway)

tags: added: rls-bb-notfixing
removed: rls-bb-incoming
Sebastien Bacher (seb128) wrote :

upstream g-s-d asked for a name change but otherwise it seems fine in principle

Gunnar Hjalmarsson (gunnarhj) wrote :

This is an important improvement, so I have no objections from a docs and/or translators POV.

One plea, though: To the extent this introduces new or changed translatable strings, please notify the translators on the ubuntu-translators list once those strings have been made available for translation.

Iain Lane (laney) wrote :

The systemd part is OK since it's cherry-picks - +1 for uploading that.

For g-s-d I would prefer to wait for it to be more firm upstream, especially with regard to the naming. So I vote for waiting until it's committed there. It might be helpful/useful/necessary for that to hang out on #control-center on gnome IRC.

You don't plan any UI changes for 18.04, right? As an aside, it seems like there probably should be some UI for this in the future.

Gsd is pushing for the name change in systemd, so I'm going to get that
upstreamed before bringing this into Ubuntu. (Suspend to hibernate to
suspend then hibernate).

In terms of UI where would it Land? I figure it should be a policy setting
on systems that ship with it, but you're probably right that policy should
be viewable and changeable if someone doesn't want this.

On Wed, Mar 28, 2018, 09:21 Iain Lane <email address hidden> wrote:

> The systemd part is OK since it's cherry-picks - +1 for uploading that.
>
> For g-s-d I would prefer to wait for it to be more firm upstream,
> especially with regard to the naming. So I vote for waiting until it's
> committed there. It might be helpful/useful/necessary for that to hang
> out on #control-center on gnome IRC.
>
> You don't plan any UI changes for 18.04, right? As an aside, it seems
> like there probably should be some UI for this in the future.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1756006
>
> Title:
> FFe: Support suspend-to-hibernate
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1756006/+subscriptions
>

The rename is done upstream, it's now suspend-then-hibernate. I'm uploading systemd with these patches.

As for G-S-D, I've adjusted it for the rename too but it's still waiting to be merged.

Changed in systemd (Ubuntu):
status: New → Fix Committed
summary: - FFe: Support suspend-to-hibernate
+ FFe: Support suspend-then-hibernate
Dimitri John Ledkov (xnox) wrote :

@superm1

It would have been nice to coordinate systemd uploads, this is by far, not the only patch set that needs uploading for systemd.

tags: added: block-proposed
Iain Lane (laney) wrote :

(cleaning up ~ubuntu-release bugs)

Incomplete for g-s-d - please could you reset once this is accepted upstream?

Changed in gnome-settings-daemon (Ubuntu):
status: New → Incomplete
Iain Lane (laney) on 2018-04-06
tags: removed: block-proposed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 237-3ubuntu7

---------------
systemd (237-3ubuntu7) bionic; urgency=medium

  * Introduce suspend then hibernate (LP: #1756006)

 -- Mario Limonciello <email address hidden> Mon, 02 Apr 2018 14:25:04 -0500

Changed in systemd (Ubuntu):
status: Fix Committed → Fix Released
Jeremy Bicha (jbicha) wrote :
Changed in gnome-settings-daemon (Ubuntu):
status: Incomplete → New

On Thu, Apr 12, 2018 at 12:41:30PM -0000, Jeremy Bicha wrote:
> Resetting to New since the g-s-d commits have been accepted upstream.
> They are the first 4 commits for 12 Apr, 2018.
>
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commits/master

The new version is to automatically select this policy if systemd
supports it, right?

What makes systemd answer yes to that question? Is there a chance that
existing machines could start using this and it could be broken for
them?

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Sebastien Bacher (seb128) wrote :

The changes got commited to upstream master, we might want to backport/SRU in bionic?

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Mario Limonciello (superm1) wrote :

Well at least with what's upstream it's not working with what was committed
for me.

The other problem I find is that gnome-power-manager sets some policy
actions and systemd sets others. For example systemd is controlling the
lid action but gnome power manager is controlling the timeout action. The
action is hardcoded right now in systemd.
So unless systemd adopts a similar prefer suspend then hibernate over
suspend policy if possible this could cause a confusing experience.

On Tue, May 1, 2018 at 10:11 AM Sebastien Bacher <email address hidden> wrote:

> The changes got commited to upstream master, we might want to
> backport/SRU in bionic?
>
> ** Changed in: gnome-settings-daemon (Ubuntu)
> Importance: Undecided => Wishlist
>
> ** Changed in: gnome-settings-daemon (Ubuntu)
> Status: New => Triaged
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1756006
>
> Title:
> FFe: Support suspend-then-hibernate
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1756006/+subscriptions
>

--
Mario Limonciello
<email address hidden>

Jeremy Bicha (jbicha) wrote :

Ubuntu 18.10 has this feature as part of GNOME 3.30.

There are some complaints though:
https://lwn.net/Articles/764841/
https://bugs.debian.org/908930

On the other hand, Simon's comment on the Debian bug indicates that feature won't work if the system uses a swap file which Ubuntu 18.04 LTS and newer does by default.

Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → Fix Released
Changed in gnome-settings-daemon (Ubuntu Bionic):
status: New → Triaged
importance: Undecided → Low
no longer affects: systemd (Ubuntu Bionic)
Dimitri John Ledkov (xnox) wrote :

sufficiently large swapfile should be enough, as systemd has support to hibernate to a file offset.
However, none-the-less, I did not manage to resume off that myself yet.

Mario Limonciello (superm1) wrote :

When I did those PR upstream I did it with a swapfile actually on Ubuntu. The key comes down to how initramfs-tools hands off the offsets. It's kinda a jumbled mess though.

I started a discussion here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890950
but it got stalled and I got busy with other stuff and didn't resume it.

Jeremy Bicha (jbicha) wrote :

I used d-feet to Execute org.freedesktop.login1 org.freedesktop.login1.Manager CanSuspendThenHibernate

If my swapfile was too small, I got the response 'na'. When I used a bigger swapfile, I got the response 'no'.

Mario Limonciello (superm1) wrote :

Try d-feet as root. I think I recalled seeing this too.

Jeremy Bicha (jbicha) wrote :

GNOME is discussing reverting this change for 3.30. Posted moments ago in #control-center on irc.gnome.org:

benzea > I am getting tempted to consider reverting the change. two of the four "common" suspend scenarios are not even covered by g-s-d i.e. if you close the lid or use alt+click in the gnome-shell dropdown, you do a suspend.
we only changed the meaning of "suspend" for inactivity and pressing the hardware power button
https://p.sipsolutions.net/65caa390fcbd0e00.txt <- for a summary of suspend reasons

Changed in gnome-settings-daemon (Ubuntu):
status: Fix Released → Triaged
Jeremy Bicha (jbicha) wrote :

Mario, I believe GNOME is planning to do a gnome-settings-daemon 3.30.1.2 release soon disabling the feature by default (at compile time). See https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/78 and its attached merge proposal especially the NEWS entry.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.