Re: Who is sending my Guix System to sleep?

[Jack Hill <jackhill@jackhill.us>]

On Fri, 11 Oct 2019, Ludovic Courtès wrote:

> Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:
>
>> The only problem is that after 20 minutes, the virtual machine
>> seems to freeze.

I've experienced unwanted suspends as well on a desktop system when not 
logged in graphically.

>> I found the cause in /var/log/messages:
>>
>>     Sep 26 08:54:40 localhost NetworkManager[282]: <info>  [1569480880.2246] manager: sleep: sleep requested (sleeping: no  enabled: yes)
>>     Sep 26 08:54:40 localhost NetworkManager[282]: <info>  [1569480880.2247] manager: NetworkManager state is now ASLEEP
>>     Sep 26 08:54:40 localhost NetworkManager[282]: <info>  [1569480880.2248] device (enp0s3): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
>>     Sep 26 08:54:40 localhost NetworkManager[282]: <info>
>>     [1569480880.2293] device (enp0s3): state change: deactivating ->
>>     disconnected (reason 'sleeping', sys-iface-state: 'managed')
>>
>> Something requests NetworkManager to go to sleep, which is obviously not
>> good for my ssh connection. But what?

I believe that NetworkManager is more of a symptom than a cause, and it is 
not really related to networking, but NetworkManager happens to be the 
most helpful thing by printing the error messages.

> I think elogind is the thing you’d want to configure to turn off
> automatic standby when the machine is idle, presumably by changing the
> ‘idle-action’ field of <elogind-configuration>?
>
> logind.conf(5) is not entirely clear, though:

Also, it looks like we're already setting idle-action to ignore by 
default[0], so I was skeptical that this is what was triggering the 
suspend.

[0] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/desktop.scm?id=cdc81ccedb332fb297f6100ccd99eaf13d161ada#n618

My particular symptoms are that when I log into a graphical GNOME session 
from gdm, the machine does not suspend unexpectedly, and follows the 
settings that I have configured in GNOME Settings. However, if I'm not 
logged in, and the computer is waiting at the gdm greater, the unwanted 
suspension happens.

I believe what is happening is when a user is logged in, their settings 
are in force, but when no user is logged in, it is the gdm user's settings 
that are effective.

After some searching online [1][2][3], it appears that the following dconf 
settings are the important ones:

/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type
/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout

[1] https://unix.stackexchange.com/questions/361214/disable-gdm-suspend-on-lock-screen
[2] https://bbs.archlinux.org/viewtopic.php?id=132376
[3] https://wiki.archlinux.org/index.php/GNOME#Login_screen

I changed sleep-inactive-ac-type imperatively by becoming the gdm user 
and then running dconf command as follows

```
# su - gdm -s /run/current-system/profile/bin/sh
-sh-5.0$ export $(dbus-launch)
-sh-5.0$ dconf write /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type "'blank'"
```

Note the double quoting around blank. This is important when running at 
the shell because the single quotes are part of the value so that its type 
can determined.

After running the dconf command a /var/lib/gdm/.config/dconf/user file is 
created to hold this setting, and (at least after restarting the host, I 
don't know if this is necessary, but it's what I did) the computer no 
longer suspends while waiting for a user to login.

It would be great to be able to handle dconf settings in the gdm-service. 
It would be even greater to have general dconf settings mechanisms to 
handle settings stored in that database for any service that uses it. I 
could see this being useful to guix home as well as any work to clean up 
stateful system directories [4]. Perhaps the dconf settings mechanisms 
could even look at schemas to aid in generating code and only provide the 
user with ways to write correct configuration.

[4] https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html

Best,
Jack