unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: 57490@debbugs.gnu.org
Subject: bug#57490: UPower ignores ‘critical-power-action’
Date: Wed, 31 Aug 2022 16:46:04 +0200	[thread overview]
Message-ID: <87wnaoa2tv.fsf@gnu.org> (raw)
In-Reply-To: <871qsxe6ol.fsf@gnu.org> ("Ludovic Courtès"'s message of "Tue, 30 Aug 2022 23:56:58 +0200")

Ludovic Courtès <ludo@gnu.org> skribis:

> Setting ‘hybrid-sleep-state’ to '("mem") doesn’t help though:
> “CanHybridSleep” still returns “na”.  I’m looking at ‘can_sleep_state’
> in elogind without seeing why it doesn’t return true.

Having changed elogind’s “LogLevel” to “debug” with a 1km-long
‘dbus-send’ command I’ll spare you, I got this in /var/log/debug for my
“CanHybridSleep” method call (in QEMU):

--8<---------------cut here---------------start------------->8---
Aug 31 16:01:07 localhost elogind[183]: Got message type=method_call sender=:1.78 destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CanHybridSleep cookie=2 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Aug 31 16:01:07 localhost elogind[183]: Sleep mode "mem" is supported by the kernel.
Aug 31 16:01:07 localhost elogind[183]: No possible swap partitions or files suitable for hibernation were found in /proc/swaps.
Aug 31 16:01:07 localhost elogind[183]: Sent message type=method_return sender=n/a destination=:1.78 path=n/a interface=n/a member=n/a cookie=190 reply_cookie=2 signature=s error-name=n/a error-message=n/a
--8<---------------cut here---------------end--------------->8---

Closer inspection of the code confirms what we can guess from the above:
if swap space is missing, ‘can_sleep’ returns false, even if the chosen
sleep state is “mem”:

--8<---------------cut here---------------start------------->8---
static int can_sleep_internal(const char *verb, bool check_allowed, const SleepConfig *sleep_config) {
        bool allow;
        char **modes = NULL, **states = NULL;
        int r;

        assert(STR_IN_SET(verb, "suspend", "hibernate", "hybrid-sleep", "suspend-then-hibernate"));

[...]

#if 0 /// elogind supports setting a suspend mode
        if (!can_sleep_state(states) || !can_sleep_disk(modes))
                return false;
#else // 0
        if (!can_sleep_state(states) ||
            !((strcmp("suspend", verb) && can_sleep_disk(modes)) ||
              (streq("suspend", verb) && can_sleep_mem(modes))))
                return false;
#endif // 0

        if (streq(verb, "suspend"))
                return true;

        if (!enough_swap_for_hibernation())
                return -ENOSPC;

        return true;
}
--8<---------------cut here---------------end--------------->8---

(Specifically, ‘enough_swap_for_hibernation’ returns false when there’s
no space space.)

The caller:

--8<---------------cut here---------------start------------->8---
static int method_can_shutdown_or_sleep(
                Manager *m,
                sd_bus_message *message,
                InhibitWhat w,
                const char *action,
                const char *action_multiple_sessions,
                const char *action_ignore_inhibit,
                const char *sleep_verb,
                sd_bus_error *error) {

[...]

        if (sleep_verb) {
#if 0 /// elogind needs to have the manager being passed
                r = can_sleep(sleep_verb);
#else // 0
                r = can_sleep(m, sleep_verb);
#endif // 0
                if (IN_SET(r,  0, -ENOSPC))
                        return sd_bus_reply_method_return(message, "s", "na");
                if (r < 0)
                        return r;
        }
--8<---------------cut here---------------end--------------->8---

I find it a bit ridiculous: if we’re choosing “mem”, then we shouldn’t
need to check for swap space.

However, given how ‘hybrid-sleep’ is documented¹, it’s not meant to be
implemented by suspend-to-RAM:

  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. This mode is called
  suspend-to-both by the kernel.

So, as a conclusion, it would seem that everything here is working as
advertised: no swap, no hybrid-sleep.  (We should probably document that
in the manual.)


One issue remains: UPower should have called elogind’s “PowerOff” method
for ordered shutdown before total power outage, but either that didn’t
happen or elogind didn’t do it right (which is weird, because ‘loginctl
poweroff’ DTRT.)

Thoughts?

Ludo’.

¹ https://man.voidlinux.org/logind.conf.5




  reply	other threads:[~2022-08-31 14:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 15:59 bug#57490: UPower ignores ‘critical-power-action’ Ludovic Courtès
2022-08-30 16:22 ` Ludovic Courtès
2022-08-30 21:56 ` Ludovic Courtès
2022-08-31 14:46   ` Ludovic Courtès [this message]
2022-09-05 12:56     ` Ludovic Courtès
2022-09-05 20:01       ` Maxime Devos
2022-10-02 15:27         ` Ludovic Courtès
2022-09-20 10:05       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnaoa2tv.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=57490@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).