[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Who is sending my Guix System to sleep?
From: |
Jack Hill |
Subject: |
Re: Who is sending my Guix System to sleep? |
Date: |
Tue, 22 Oct 2019 15:16:52 -0400 (EDT) |
User-agent: |
Alpine 2.20 (DEB 67 2015-01-07) |
On Fri, 11 Oct 2019, Ludovic Courtès wrote:
Konrad Hinsen <address@hidden> 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