Support suspend-then-hibernate

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

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

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

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.

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

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

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

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

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.

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.

@superm1

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

(cleaning up ~ubuntu-release bugs)

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

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

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

See also
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/13
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/9

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> ]

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

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>

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.

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.

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.

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

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

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

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.

This appears to no longer be a current FFe, so retitling and unsubscribing ubuntu-release.