Hi,
I have just done the 3GB update on my machines. Now I find that laptops and workstations go into suspend mode without being told to. For me this is not what I want. I am assuming the recent big update has included a change of setting somewhere. I am not sure where to find this. Can anyone tell me?
On Thu, 2018-02-22 at 08:39 +0000, Russel Winder wrote:
Hi,
I have just done the 3GB update on my machines. Now I find that laptops and workstations go into suspend mode without being told to. For me this is not what I want. I am assuming the recent big update has included a change of setting somewhere. I am not sure where to find this. Can anyone tell me?
It's a GNOME change to comply with EU regulations, believe it or not:
https://bugzilla.gnome.org/show_bug.cgi?id=681869 https://bugzilla.gnome.org/show_bug.cgi?id=792890
It should be configurable in the Power panel of the control center.
Adam,
Thanks for the quick answer, much appreciated. I may get grumpy on this one, hopefully no-one takes offence.
On Thu, 2018-02-22 at 02:25 -0800, Adam Williamson wrote:
On Thu, 2018-02-22 at 08:39 +0000, Russel Winder wrote:
Hi,
I have just done the 3GB update on my machines. Now I find that laptops and workstations go into suspend mode without being told to. For me this is not what I want. I am assuming the recent big update has included a change of setting somewhere. I am not sure where to find this. Can anyone tell me?
It's a GNOME change to comply with EU regulations, believe it or not:
https://bugzilla.gnome.org/show_bug.cgi?id=681869 https://bugzilla.gnome.org/show_bug.cgi?id=792890
OK it seems an interpretation of an EU regulation has finally convinced me BrExit might actually have an upside. :-(
I think GNOME developers should also read 7.b.3.b:
Equipment shall, unless inappropriate for the intended use, offer a power management function or a similar function.
GNOME can certainly count in the inappropriate for the intended use category.
In any event this should be an easily opt out of.
It should be configurable in the Power panel of the control center.
Do you know if there is there a way of setting it without logging in to the console device? GNOME will hopefully not then reset a value it has no right to set without consent.
My set up has a server, one workstation/server, and three laptops all up and working. I am only logged into one. Now the workstation/server (which should never stop as it has a server role) and two laptops spontaneously suspend, which f#### everything up. :-(
I guess I am going to have a problem with my server which actually has GNOME installed for various reasons.
On Thu, 2018-02-22 at 11:17 +0000, Russel Winder wrote:
It should be configurable in the Power panel of the control center.
Do you know if there is there a way of setting it without logging in to the console device? GNOME will hopefully not then reset a value it has no right to set without consent.
Anything settable in control-center is likely backed with a dconf key you could set.
My set up has a server, one workstation/server, and three laptops all up and working. I am only logged into one. Now the workstation/server (which should never stop as it has a server role) and two laptops spontaneously suspend, which f#### everything up. :-(
I guess I am going to have a problem with my server which actually has GNOME installed for various reasons.
I'd think this would only take effect if a GNOME session is actually *running*. Though GDM might count.
On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
[…]
Anything settable in control-center is likely backed with a dconf key you could set.
True. Finding the path to the key is not always obvious though. I am guessing that in this case org.gnome.session-daemon may be the place.
[…]
I'd think this would only take effect if a GNOME session is actually *running*. Though GDM might count.
I think GDM does indeed count since it and GnomeShell appear to be tightly coupled.
Sadly gnome-control-centre fails to work over an SSH link with Wayland :-(
On 22 February 2018 at 14:58, Russel Winder russel@winder.org.uk wrote:
On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
[…]
Anything settable in control-center is likely backed with a dconf key you could set.
True. Finding the path to the key is not always obvious though. I am guessing that in this case org.gnome.session-daemon may be the place.
$ gsettings list-keys org.gnome.settings-daemon.plugins.power
(I usually find that grep'ing in '/usr/share/glib-2.0/schemas/' is sort of faster/easier).
[....]
On Thu, Feb 22, 2018 at 04:00:44PM +0200, Ahmad Samir wrote:
On 22 February 2018 at 14:58, Russel Winder russel@winder.org.uk wrote:
On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
[…]
Anything settable in control-center is likely backed with a dconf key you could set.
True. Finding the path to the key is not always obvious though. I am guessing that in this case org.gnome.session-daemon may be the place.
$ gsettings list-keys org.gnome.settings-daemon.plugins.power
(I usually find that grep'ing in '/usr/share/glib-2.0/schemas/' is sort of faster/easier).
This still leaves a question how you are going to modify that for gdm on a machine of a type "server - most of the time"? If I understood Russel correctly such setup is hugely affected.
Michal
On 22 February 2018 at 18:39, Michal Jaegermann michal.jnn@gmail.com wrote:
On Thu, Feb 22, 2018 at 04:00:44PM +0200, Ahmad Samir wrote:
On 22 February 2018 at 14:58, Russel Winder russel@winder.org.uk wrote:
On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
[…]
Anything settable in control-center is likely backed with a dconf key you could set.
True. Finding the path to the key is not always obvious though. I am guessing that in this case org.gnome.session-daemon may be the place.
$ gsettings list-keys org.gnome.settings-daemon.plugins.power
(I usually find that grep'ing in '/usr/share/glib-2.0/schemas/' is sort of faster/easier).
This still leaves a question how you are going to modify that for gdm on a machine of a type "server - most of the time"? If I understood Russel correctly such setup is hugely affected.
Michal
I missed that part, sorry. One (hackish) way would be to create a new user account, modify only those gsettings keys then copy ~/.config/dconf/user to (the gdm user home dir[1]) /var/lib/gdm/.config/ and of course make the file owned by gdm.
I haven't tested that method though; but IIRC, one way to get gdm to use custom multiple monitor settings was to copy ~/.config/monitors.xml (created by the display module of gnome-control-center) from your regular user account to /var/lib/gdm/.config/ .
I hope that helps.
[1] which I could see/guess in /etc/passwd.
On Thu, 2018-02-22 at 09:39 -0700, Michal Jaegermann wrote:
On Thu, Feb 22, 2018 at 04:00:44PM +0200, Ahmad Samir wrote:
On 22 February 2018 at 14:58, Russel Winder russel@winder.org.uk wrote:
On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
[…]
Anything settable in control-center is likely backed with a dconf key you could set.
True. Finding the path to the key is not always obvious though. I am guessing that in this case org.gnome.session-daemon may be the place.
$ gsettings list-keys org.gnome.settings-daemon.plugins.power
(I usually find that grep'ing in '/usr/share/glib-2.0/schemas/' is sort of faster/easier).
This still leaves a question how you are going to modify that for gdm on a machine of a type "server - most of the time"? If I understood Russel correctly such setup is hugely affected.
Doing dconf configuration for gdm is a relatively common 'gotcha' as there are various cases where people need it for one reason or another. The Alternative Fedora Wiki has some good tips:
https://wiki.archlinux.org/index.php/GDM#DConf_configuration
Hi,
Back after a period away.
On Thu, 2018-02-22 at 09:39 -0700, Michal Jaegermann wrote: […]
This still leaves a question how you are going to modify that for gdm on a machine of a type "server - most of the time"? If I understood Russel correctly such setup is hugely affected.
It seems that if you login on the console (SSH over Ethernet is not enough) then the GNOME settings are activated and suspend only happens on battery – this is the situation I need ad have set. However, without login Fedora Rawhide suspends after a short period, Debian id does not. I need to have computers powered up and not logged in on the console, I login over SSH. Debian gives me this Fedora does not.
I am guessing default GDM suspend settings are different in Debian and Fedora. Debian works as I want to, Fedora does not. Of course, this may just be my problem.
On Sat, 2018-03-17 at 12:09 +0000, Russel Winder wrote:
Hi,
Back after a period away.
On Thu, 2018-02-22 at 09:39 -0700, Michal Jaegermann wrote: […]
This still leaves a question how you are going to modify that for gdm on a machine of a type "server - most of the time"? If I understood Russel correctly such setup is hugely affected.
It seems that if you login on the console (SSH over Ethernet is not enough) then the GNOME settings are activated and suspend only happens on battery – this is the situation I need ad have set. However, without login Fedora Rawhide suspends after a short period, Debian id does not. I need to have computers powered up and not logged in on the console, I login over SSH. Debian gives me this Fedora does not.
I am guessing default GDM suspend settings are different in Debian and Fedora. Debian works as I want to, Fedora does not. Of course, this may just be my problem.
OK so Debian Sid has now fully updated GNOME and it behaves the same as Fedora Rawhide. If you are not logged in on the console, GDM suspends the computer after a few minutes. GNOME has just ruined my life.
On Sun, 2018-03-18 at 12:32 +0000, Russel Winder wrote:
On Sat, 2018-03-17 at 12:09 +0000, Russel Winder wrote:
Hi,
Back after a period away.
On Thu, 2018-02-22 at 09:39 -0700, Michal Jaegermann wrote: […]
This still leaves a question how you are going to modify that for gdm on a machine of a type "server - most of the time"? If I understood Russel correctly such setup is hugely affected.
It seems that if you login on the console (SSH over Ethernet is not enough) then the GNOME settings are activated and suspend only happens on battery – this is the situation I need ad have set. However, without login Fedora Rawhide suspends after a short period, Debian id does not. I need to have computers powered up and not logged in on the console, I login over SSH. Debian gives me this Fedora does not.
I am guessing default GDM suspend settings are different in Debian and Fedora. Debian works as I want to, Fedora does not. Of course, this may just be my problem.
OK so Debian Sid has now fully updated GNOME and it behaves the same as Fedora Rawhide. If you are not logged in on the console, GDM suspends the computer after a few minutes. GNOME has just ruined my life.
Glad to know you're being reasonable and proportional in response to a default configuration change!
You can configure this in the Control Center. Settings / Power / Automatic suspend: turn it "off". Now you're done.
On Mon, Mar 19, 2018 at 5:16 PM, Adam Williamson <adamwill@fedoraproject.org
wrote:
OK so Debian Sid has now fully updated GNOME and it behaves the same as
Fedora
Rawhide. If you are not logged in on the console, GDM suspends the
computer
after a few minutes. GNOME has just ruined my life.
Glad to know you're being reasonable and proportional in response to a default configuration change!
You can configure this in the Control Center. Settings / Power / Automatic suspend: turn it "off". Now you're done.
On Tue, 2018-03-20 at 13:54 +0100, Kamil Paral wrote:
[…]
Exactly, thanks for posting the bug report.
Extremely angry is a bit of an understatement!
I do hope the GNOME people accept this as a problem and provide a way of switching this suspend behaviour off.
On Tue, 2018-03-20 at 13:48 +0000, Russel Winder wrote:
On Tue, 2018-03-20 at 13:54 +0100, Kamil Paral wrote:
[…]
Exactly, thanks for posting the bug report.
Extremely angry is a bit of an understatement!
I do hope the GNOME people accept this as a problem and provide a way of switching this suspend behaviour off.
Technically there is a way: you just have to figure out how to change the setting for the 'gdm' user. The Alternative Fedora Wiki has something on this:
https://wiki.archlinux.org/index.php/GDM#DConf_configuration
I think I've done it by running gsettings as 'gdm' before, though it's a bit of a pain as the account is set up by default such that you can't really switch to it. I think I either hacked up the account definition temporarily, or wrote a script that made the changes and ran the script with 'runuser'.
On Tue, 2018-03-20 at 12:31 -0700, Adam Williamson wrote:
On Tue, 2018-03-20 at 13:48 +0000, Russel Winder wrote:
On Tue, 2018-03-20 at 13:54 +0100, Kamil Paral wrote:
[…]
Exactly, thanks for posting the bug report.
Extremely angry is a bit of an understatement!
I do hope the GNOME people accept this as a problem and provide a way of switching this suspend behaviour off.
Technically there is a way: you just have to figure out how to change the setting for the 'gdm' user. The Alternative Fedora Wiki has something on this:
https://wiki.archlinux.org/index.php/GDM#DConf_configuration
I think I've done it by running gsettings as 'gdm' before, though it's a bit of a pain as the account is set up by default such that you can't really switch to it. I think I either hacked up the account definition temporarily, or wrote a script that made the changes and ran the script with 'runuser'. --
It may be posible to do the following from root: su - gdm -s /bin/bash
to change to user gdm and still get a shell? BR, Louis
On Tue, 2018-03-20 at 20:38 +0100, Louis Lagendijk wrote:
On Tue, 2018-03-20 at 12:31 -0700, Adam Williamson wrote:
On Tue, 2018-03-20 at 13:48 +0000, Russel Winder wrote:
On Tue, 2018-03-20 at 13:54 +0100, Kamil Paral wrote:
[…]
[…]
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/22#note_91428
Seems to be the official answer from GNOME. And, per se, it seems entirely reasonable.
The Debian bit works exactly as stated, so happiness achieved there. But for Fedora, I haven't made things work.
Technically there is a way: you just have to figure out how to change the setting for the 'gdm' user. The Alternative Fedora Wiki has something on this:
https://wiki.archlinux.org/index.php/GDM#DConf_configuration
This seems to indicate that a way forward is to symbolic link /usr/share/dconf/profile/gdm to /etc/dconf/profile/gdm and then create a directory /etc/dconf/db/gdm.d and add to it a file 99-local-settings containing:
[org/gnome/settings-daemon/plugins/power] sleep-inactive-ac-timeout=0 sleep-inactive-battery-timeout=0
and then run "dconf update". This created /etc/dconf/db/gdm indicating possible success.
Reboot, but no luck still suspends. :-(
[…]
It may be posible to do the following from root: su - gdm -s /bin/bash
to change to user gdm and still get a shell?
This works fine it seems:
[root@lavaine ~]# su - gdm -s /bin/sh [gdm@lavaine ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lavaine ~]$
So the key is there (which is wasn't initially) but the value is wrong. I am clearly missing something. Hopefully something simple.
On 04/01/2018 03:08 AM, Russel Winder wrote:
[root@lavaine ~]# su - gdm -s /bin/sh [gdm@lavaine ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lavaine ~]$
So the key is there (which is wasn't initially) but the value is wrong. I am clearly missing something. Hopefully something simple.
Did you try setting the value?
On Sun, 2018-04-01 at 17:46 -0700, Samuel Sieb wrote:
On 04/01/2018 03:08 AM, Russel Winder wrote:
[root@lavaine ~]# su - gdm -s /bin/sh [gdm@lavaine ~]$ gsettings get org.gnome.settings- daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lavaine ~]$
So the key is there (which is wasn't initially) but the value is wrong. I am clearly missing something. Hopefully something simple.
Did you try setting the value?
[gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200 [gdm@lionors ~]$ [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200 [gdm@lionors ~]$ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0 [gdm@lionors ~]$ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
(process:2126): dconf-WARNING **: 10:07:48.286: failed to commit changes to dconf: Cannot autolaunch D-Bus without X11 $DISPLAY [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200 [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lionors ~]$
Hi,
I have no idea what happened or what changed, but I didn't do anything further and yet:
[root@lionors ~]# su - gdm -s /bin/sh [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
and the computer does not auto suspend whilst in "GDM mode". Result.
I am assuming having a few reboots as well as updates has made the difference. Anyway, I am now a happy bunny.
On Mon, 2018-04-02 at 10:17 +0100, Russel Winder wrote:
On Sun, 2018-04-01 at 17:46 -0700, Samuel Sieb wrote:
On 04/01/2018 03:08 AM, Russel Winder wrote:
[root@lavaine ~]# su - gdm -s /bin/sh [gdm@lavaine ~]$ gsettings get org.gnome.settings- daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lavaine ~]$
So the key is there (which is wasn't initially) but the value is wrong. I am clearly missing something. Hopefully something simple.
Did you try setting the value?
[gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200 [gdm@lionors ~]$ [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200 [gdm@lionors ~]$ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0 [gdm@lionors ~]$ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
(process:2126): dconf-WARNING **: 10:07:48.286: failed to commit changes to dconf: Cannot autolaunch D-Bus without X11 $DISPLAY [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200 [gdm@lionors ~]$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1200 [gdm@lionors ~]$
On Mon, 2018-03-19 at 09:16 -0700, Adam Williamson wrote:
[…]
Glad to know you're being reasonable and proportional in response to a default configuration change!
On the one hand :-), on the other hand: the current situation means I have to login to all the computers from the console so as to stop the automatic suspend. This means I cannot do any non-local reboots.
You can configure this in the Control Center. Settings / Power / Automatic suspend: turn it "off". Now you're done.
No I am not, I'm afraid. I have that set already on all my computers; these settings only apply once you are logged in to the console.
The problem remains, there must be a GNOMEShell/GDM setting separate from the user power setting that applies after a reboot but before a login. The question is how to change this altered configuration setting that is nothing to do with the user.
...
You can configure this in the Control Center. Settings / Power / Automatic suspend: turn it "off". Now you're done.
beside Kamil's bug, isn't GNOME moving to Wayland?
how to configure that when I was unable to run g-c-c over ssh? -
... DISTRO=Fedora-Rawhide-20180319.n.0 ARCHITECTURE=x86_64 ... [root@sweetpig-15 ~]# echo $DISPLAY localhost:10.0 [root@sweetpig-15 ~]# gnome-control-center
(process:5949): Gtk-WARNING **: 09:40:32.291: Locale not supported by C library. Using the fallback 'C' locale.
(gnome-control-center:5949): Clutter-WARNING **: 09:40:43.725: Locale not supported by C library. Using the fallback 'C' locale. libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast
(gnome-control-center:5949): Gdk-ERROR **: 09:40:54.025: The program 'gnome-control-center' received an X Window System error. This probably reflects a bug in the program. The error was 'GLXBadContext'. (Details: serial 208 error_code 167 request_code 154 (GLX) minor_code 6) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap (core dumped)
... is that even worth reporting? (should I try to run abrt on that machine?)
K.
On Tue, 2018-03-20 at 14:49 +0100, Karel Volný wrote:
...
You can configure this in the Control Center. Settings / Power / Automatic suspend: turn it "off". Now you're done.
beside Kamil's bug, isn't GNOME moving to Wayland?
how to configure that when I was unable to run g-c-c over ssh? -
Use 'gsettings'.
On Tue, 2018-03-20 at 12:31 -0700, Adam Williamson wrote:
On Tue, 2018-03-20 at 14:49 +0100, Karel Volný wrote:
...
You can configure this in the Control Center. Settings / Power / Automatic suspend: turn it "off". Now you're done.
beside Kamil's bug, isn't GNOME moving to Wayland?
how to configure that when I was unable to run g-c-c over ssh? -
Use 'gsettings'.
Oh, but do it as the user that actually runs GNOME, not as root. Running 'gsettings' as root will set the configuration for root, which is usually useless.