From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Hill Subject: Re: Who is sending my Guix System to sleep? Date: Tue, 22 Oct 2019 15:16:52 -0400 (EDT) Message-ID: References: <87h84fu28y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:36213) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMzeK-0002Gl-P2 for help-guix@gnu.org; Tue, 22 Oct 2019 15:16:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iMzeJ-00056t-A2 for help-guix@gnu.org; Tue, 22 Oct 2019 15:16:56 -0400 In-Reply-To: <87h84fu28y.fsf@gnu.org> Content-ID: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: =?ISO-8859-15?Q?Ludovic_Court=E8s?= Cc: help-guix@gnu.org On Fri, 11 Oct 2019, Ludovic Courtès wrote: > Konrad Hinsen 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]: [1569480880.2246] manager: sleep: sleep requested (sleeping: no enabled: yes) >> Sep 26 08:54:40 localhost NetworkManager[282]: [1569480880.2247] manager: NetworkManager state is now ASLEEP >> Sep 26 08:54:40 localhost NetworkManager[282]: [1569480880.2248] device (enp0s3): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed') >> Sep 26 08:54:40 localhost NetworkManager[282]: >> [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 ? > > 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