I think this is really important so I created a standalone thread for this. Currently the system auto-suspends immediately after an app releases an idle lock, if the lock duration was longer than the suspend timeout. So e.g. after having watched a TV series episode in a movie player, or in a web browsers.
The bugs reports are here: https://bugzilla.gnome.org/show_bug.cgi?id=705942 https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/14 https://bugzilla.redhat.com/show_bug.cgi?id=1556790
This is very user unfriendly. However, I don't think it constitutes a blocker from QA point of view, it's just a very annoying default behavior. So, I'm writing this mail so that it doesn't slip your attention, and because Fedora Workstation SIG is the body to decide whether we want to release F28 in this state or not.
As a personal opinion, I think this was rather quickly committed without really thinking deep about the side-effects or testing it in a real-world usage for some time (this bug is a clear demonstration of that). I'd rather have this disabled for F28 and announced as a change for F29, so that we can properly test all the corner cases in advance and try to fix them. For example, has anyone tested:
a) whether downloading files in Firefox will inhibit suspend or the downloads will be aborted during progress? b) whether DNF inhibits suspend during operation or $scary_consequences? c) whether Rhythmbox inhibits suspend when playing music? d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? e) whether Pitivi inhibits suspend while rendering video? f) whether Nautilus inhibits suspend while copying files (possibly to even a remote location)?
All of these should inhibit suspend, but not idle. And there's surely so many more. This change would be an ideal candidate for a test day. Of course, we can still do it in this cycle, but the time is running short and I'm very skeptical that the app authors will be able to fix the apps in time.
What is the opinion of Fedora Workstation SIG?
On Thu, Mar 15, 2018 at 4:46 AM, Kamil Paral kparal@redhat.com wrote:
What is the opinion of Fedora Workstation SIG?
Speaking for myself here, I agree with Kamil. We should revert this change until the mutter bug is fixed, at the very least. And I'm OK with delaying it for one release cycle after that to allow more time for testing. This seems very reasonable.
Kamil, if you want to make sure this doesn't get lost, please create a ticket on https://pagure.io/fedora-workstation/issues and add the meeting tag.
Michael
On Thu, Mar 15, 2018 at 10:33 AM mcatanzaro@gnome.org wrote:
On Thu, Mar 15, 2018 at 4:46 AM, Kamil Paral kparal@redhat.com wrote:
What is the opinion of Fedora Workstation SIG?
Speaking for myself here, I agree with Kamil. We should revert this change until the mutter bug is fixed, at the very least. And I'm OK with delaying it for one release cycle after that to allow more time for testing. This seems very reasonable.
Kamil, if you want to make sure this doesn't get lost, please create a ticket on https://pagure.io/fedora-workstation/issues and add the meeting tag.
I disagree. This was not quickly committed without thinking, and I think that is a somewhat insulting thing to say.
Why do you list a long thing of things that need to work anyway, since we have a suspend option in the UI for users to turn on. Do you seriously think we just ignore all these things because the option was off by default ?
If turning suspend on by default is what it takes to get qa to pay attention, then so be it. Lets turn it on...
On Thu, Mar 15, 2018 at 10:49 AM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Mar 15, 2018 at 10:33 AM mcatanzaro@gnome.org wrote:
On Thu, Mar 15, 2018 at 4:46 AM, Kamil Paral kparal@redhat.com wrote:
What is the opinion of Fedora Workstation SIG?
Speaking for myself here, I agree with Kamil. We should revert this change until the mutter bug is fixed, at the very least. And I'm OK with delaying it for one release cycle after that to allow more time for testing. This seems very reasonable.
Kamil, if you want to make sure this doesn't get lost, please create a ticket on https://pagure.io/fedora-workstation/issues and add the meeting tag.
I disagree. This was not quickly committed without thinking, and I think that is a somewhat insulting thing to say.
I don't think proposing possible insult is a great way to deflect from the negative UX of this feature behavior, regardless of whether it's default. Default just makes the negative UX more exposed. And therefore there's going to be a pile on effect when users fall into this trap, and it is a trap.
Why do you list a long thing of things that need to work anyway, since we have a suspend option in the UI for users to turn on. Do you seriously think we just ignore all these things because the option was off by default ?
*shrug*
My imagination did get about as far as maybe these things weren't considered regardless of the option being off by default, because it's not a good UX whether it's the default or not.
If turning suspend on by default is what it takes to get qa to pay attention, then so be it. Lets turn it on...
Seems like an really adversarial way of getting Fedora QA to due enhanced testing for something. I don't know, maybe ask first? Maybe ask for a Fedora Test Day?
On Thu, Mar 15, 2018 at 5:49 PM, Matthias Clasen mclasen@redhat.com wrote:
I disagree. This was not quickly committed without thinking, and I think that is a somewhat insulting thing to say.
It wasn't meant to be insulting, but you also cut my sentence short. The other part was "or testing it in a real-world usage for some time". I honestly believed that none of the core developers who decided about this change had auto-suspend enabled, because otherwise the inhibitor bug [1] would be considered a blocker for that change. But different people have different opinions and priorities, and maybe you're running with auto-suspend enabled, and maybe don't mind auto-suspending after having watched a TV episode and think it's not a problem. That's exactly why I reached out to this list.
I don't personally need to know your opinions on this. You (the SIG) decide what feature to put it, what to leave out, whether to re-evaluate it. I'm simply notifying you of a potentially annoying issue for our userbase. I wouldn't want to hear in the future that QA missed this.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=705942
Why do you list a long thing of things that need to work anyway, since we have a suspend option in the UI for users to turn on. Do you seriously think we just ignore all these things because the option was off by default ?
I don't know, that's why I asked. Do they all work?
My assumption is that the apps developers didn't need to care much about suspend, because it was off by default. When manually suspending, the user makes sure no important task gets cancelled or jeopardised (downloading a file, running a dnf operation). Surely there is a small percentage of users who turned autosuspend on, but many of those might feel like "I know what I'm doing, and if some task gets aborted due to autosuspend, it's my fault, because this was off by default". With autosuspend suddenly on by default, the perception changes - the system now should guarantee everything works fine, because it's the default setting. At least that's my understanding, you probably have a different one.
If turning suspend on by default is what it takes to get qa to pay attention, then so be it. Lets turn it on...
I don't know what to think here. Is this thread a demonstration of QA not paying attention? If you feel that there's an area where we're not paying enough attention, why don't you talk to us?
More importantly, is this feature being turned on in order to "get QA attention", or to improve the experience for our users?
On Fri, Mar 16, 2018 at 12:54:25PM +0100, Kamil Paral wrote:
suspend, because it was off by default. When manually suspending, the user makes sure no important task gets cancelled or jeopardised (downloading a file, running a dnf operation). Surely there is a small percentage of users
FWIW, DNF should correctly inhibit suspend when in the middle of an operation.
On Thu, Mar 15, 2018 at 10:32 AM, mcatanzaro@gnome.org wrote:
On Thu, Mar 15, 2018 at 4:46 AM, Kamil Paral kparal@redhat.com wrote:
What is the opinion of Fedora Workstation SIG?
Speaking for myself here, I agree with Kamil. We should revert this change until the mutter bug is fixed, at the very least. And I'm OK with delaying it for one release cycle after that to allow more time for testing. This seems very reasonable.
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years. So it's not like there was a sudden leap into untested territory - this is the way that many people experience Fedora. So I don't think the lack of inhibitors in every possible app is a blocker. And if we can improve the case where inhibition is longer than the suspend delay - that strikes me as much more of a positive step forward than toggling back the behavior on AC power.
Owen
Kamil, if you want to make sure this doesn't get lost, please create a ticket on https://pagure.io/fedora-workstation/issues and add the meeting tag.
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Thu, Mar 15, 2018 at 01:59:08PM -0400, Owen Taylor wrote:
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years. So it's not like there was a sudden leap into untested territory - this is the way that many people experience Fedora. So I don't think the lack of inhibitors in every possible app is a blocker. And if we can improve the case where inhibition is longer than the suspend delay - that strikes me as much more of a positive step forward than toggling back the behavior on AC power.
We're going to get backlash if we don't communicate this well. I'm used to making sure I'm plugged in if I have a long-running task to prevent suspend. I don't think it's a big deal to adjust behavior* but we'll definitely garner some annoyed and surprised users unhappy about learing this the hard way if we're not careful.
----
* it may be nice to prominently offer a version of the Caffeine extension which can toggle between normal, inhibit suspend, and inhibit screen off
On Thu, Mar 15, 2018 at 2:14 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Mar 15, 2018 at 01:59:08PM -0400, Owen Taylor wrote:
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years. So it's not like there was a sudden leap into untested territory - this is the way that many people experience Fedora. So I don't think the lack of inhibitors in
every
possible app is a blocker. And if we can improve the case where
inhibition
is longer than the suspend delay - that strikes me as much more of a positive step forward than toggling back the behavior on AC power.
We're going to get backlash if we don't communicate this well. I'm used to making sure I'm plugged in if I have a long-running task to prevent suspend. I don't think it's a big deal to adjust behavior* but we'll definitely garner some annoyed and surprised users unhappy about learing this the hard way if we're not careful.
- it may be nice to prominently offer a version of the Caffeine
extension which can toggle between normal, inhibit suspend, and inhibit screen off
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Thu, Mar 15, 2018 at 2:14 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Mar 15, 2018 at 01:59:08PM -0400, Owen Taylor wrote:
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years. So it's not like there was a sudden leap into untested territory - this is the way that many people experience Fedora. So I don't think the lack of inhibitors in
every
possible app is a blocker. And if we can improve the case where
inhibition
is longer than the suspend delay - that strikes me as much more of a positive step forward than toggling back the behavior on AC power.
We're going to get backlash if we don't communicate this well. I'm used to making sure I'm plugged in if I have a long-running task to prevent suspend. I don't think it's a big deal to adjust behavior* but we'll definitely garner some annoyed and surprised users unhappy about learing this the hard way if we're not careful.
While people may be annoyed the first time their kernel compile gets suspended, hopefully the response will to go look for the quick control center toggle to get back to the old behavior. And the old behavior when on AC power is probably what you want if you are a user who compiles kernels, encodes videos from the command line, etc.
(I'm not sure there's any good way to distinguish intentional long-running command line jobs from run-away processes...)
Owen
P.S. Bastien told me on IRC that I was wrong and we weren't defaulting to suspend on battery - I was just confused by the way different GSettings keys interacted. But certainly suspending on idle when on battery is what people expect laptops to do!
On Thu, 2018-03-15 at 14:33 -0400, Owen Taylor wrote:
On Thu, Mar 15, 2018 at 2:14 PM, Matthew Miller <mattdm@fedoraproject .org> wrote:
On Thu, Mar 15, 2018 at 01:59:08PM -0400, Owen Taylor wrote:
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years. So it's not like there was a sudden leap into untested territory - this is the way that many people experience Fedora. So I don't think the lack of inhibitors in every possible app is a blocker. And if we can improve the case where inhibition is longer than the suspend delay - that strikes me as much more of a positive step forward than toggling back the behavior on AC power.
We're going to get backlash if we don't communicate this well. I'm used to making sure I'm plugged in if I have a long-running task to prevent suspend. I don't think it's a big deal to adjust behavior* but we'll definitely garner some annoyed and surprised users unhappy about learing this the hard way if we're not careful.
While people may be annoyed the first time their kernel compile gets suspended, hopefully the response will to go look for the quick control center toggle to get back to the old behavior. And the old behavior when on AC power is probably what you want if you are a user who compiles kernels, encodes videos from the command line, etc.
(I'm not sure there's any good way to distinguish intentional long- running command line jobs from run-away processes...)
One option is to wrap the long-running command as follows:
$ gnome-session-inhibit --inhibit idle COMMAND ARGS …
This way, you can leave a long build (e.g build a Flatpak SDK) running as you go to sleep, the command won't be interrupted, but as soon as it finished the system will suspend, saving energy.
On Thu, Mar 15, 2018 at 02:33:16PM -0400, Owen Taylor wrote:
While people may be annoyed the first time their kernel compile gets suspended, hopefully the response will to go look for the quick control center toggle to get back to the old behavior. And the old behavior when on AC power is probably what you want if you are a user who compiles kernels, encodes videos from the command line, etc.
I'd like to at least *try* to avoid that first annoyance.
Has there ever been any work on something like initial setup which would run on upgrade and tell you what's important and new?
P.S. Bastien told me on IRC that I was wrong and we weren't defaulting to suspend on battery - I was just confused by the way different GSettings keys interacted. But certainly suspending on idle when on battery is what people expect laptops to do!
Huh. Well, I must have turned that on long ago and forgot it.
On Thu, Mar 15, 2018 at 12:33 PM, Owen Taylor otaylor@redhat.com wrote:
P.S. Bastien told me on IRC that I was wrong and we weren't defaulting to suspend on battery - I was just confused by the way different GSettings keys interacted. But certainly suspending on idle when on battery is what people expect laptops to do!
Unquestionably and I'm surprised it's not the default. And if it were, it probably would expose more problems.
I think it makes a lot more sense to make battery mode automatic suspend the default in Fedora 28, such as it is. And either delay plugged-in mode automatic suspend for Fedora 29, or at the least make it longer than 20 minutes.
On Thu, Mar 15, 2018 at 7:14 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Mar 15, 2018 at 01:59:08PM -0400, Owen Taylor wrote:
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years. So it's not like there was a sudden leap into untested territory - this is the way that many people experience Fedora. So I don't think the lack of inhibitors in
every
possible app is a blocker. And if we can improve the case where
inhibition
is longer than the suspend delay - that strikes me as much more of a positive step forward than toggling back the behavior on AC power.
We're going to get backlash if we don't communicate this well. I'm used to making sure I'm plugged in if I have a long-running task to prevent suspend. I don't think it's a big deal to adjust behavior* but we'll definitely garner some annoyed and surprised users unhappy about learing this the hard way if we're not careful.
Please note that the purpose of this thread is not to discuss auto-suspend on by default (AC and battery). It's a big change, but might not be *that* controversial, at least compared to autosuspend on by default + inhibitor bug [1] described in my first post. I think that's the biggest issue here, which I wanted to make sure is known and discussed by people in power before Fedora 28 gets released. The combination of the new feature and that bug has potential to bring us a lot of bad press, I think.
On Fri, Mar 16, 2018 at 7:01 AM, Kamil Paral kparal@redhat.com wrote:
The combination of the new feature and that bug has potential to bring us a lot of bad press, I think.
I agree that if that bug were fixed, this would be much of a problem.
On Thu, Mar 15, 2018 at 11:59 AM, Owen Taylor otaylor@redhat.com wrote:
One thing that we should be pointed out here is that we've been auto-suspending for laptops on battery for years.
This is an inexplicable statement. I have two laptop makes running Fedora for years, and I've never once experienced either of them autosuspend on battery, ever. They go to 0% and then poweroff. They do not ever suspend unless I manually suspend them with power button or alt + clicking on the power button icon in the upper right UI (which has a pause icon with alt depressed). These are default, unexotic installation.
I'm looking at the power UI right now on a clean Fedora 27 system, click on Automatic suspend, and the On Battery policy is Off, as is the Plugged In policy.
*shrug*
On Thu, Mar 15, 2018 at 10:46 AM, Kamil Paral kparal@redhat.com wrote:
For example, has anyone tested:
a) whether downloading files in Firefox will inhibit suspend or the downloads will be aborted during progress? b) whether DNF inhibits suspend during operation or $scary_consequences? c) whether Rhythmbox inhibits suspend when playing music? d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? e) whether Pitivi inhibits suspend while rendering video? f) whether Nautilus inhibits suspend while copying files (possibly to even a remote location)?
Here's another "broken" use case that we found today: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/18
Currently there seems to be no (graphical) way to disable auto-suspend system wide. Which means the system will auto-suspend regardless of your settings when you perform user switching. It's somewhat unintuitive that suspend, as a system-wide action, is considered a per-user setting (the active user overrides all inactive users), and there's no option to set it system-wide.
On Mon, Mar 19, 2018 at 1:48 PM, Kamil Paral kparal@redhat.com wrote:
On Thu, Mar 15, 2018 at 10:46 AM, Kamil Paral kparal@redhat.com wrote:
For example, has anyone tested:
a) whether downloading files in Firefox will inhibit suspend or the downloads will be aborted during progress? b) whether DNF inhibits suspend during operation or $scary_consequences? c) whether Rhythmbox inhibits suspend when playing music? d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? e) whether Pitivi inhibits suspend while rendering video? f) whether Nautilus inhibits suspend while copying files (possibly to even a remote location)?
Here's another "broken" use case that we found today: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/18
Currently there seems to be no (graphical) way to disable auto-suspend system wide. Which means the system will auto-suspend regardless of your settings when you perform user switching. It's somewhat unintuitive that suspend, as a system-wide action, is considered a per-user setting (the active user overrides all inactive users), and there's no option to set it system-wide.
Here's even a "funnier" case. The system suspends when you connect over SSH (the system shows a GDM screen locally), even if you're active (running commands). And you can't do anything about it, because it ignores your settings and uses the system default (20 minutes timeout).
So, if you sometimes start your system remotely and ssh in, or if you have graphical issues and need to debug it over ssh, or in any other case that you can imagine when you need to ssh in... your system *will* suspend in 20 minutes. I think advanced users will eat us alive.
What's even worse, there's no obvious way to disable this even for those advanced users. There's no config file in /etc you could edit and adjust. "sudo gsettings" (for setting the right key globally) fails with an error. How do GNOME devs expect users to configure this? What do we tell them? Or is ssh a no longer supported use case on Workstation?
So, I've tested some of the possible scenarios that Kamil pointed out. Here are the results:
a) whether downloading files in Firefox will inhibit suspend or the downloads will be aborted during progress? - *broken*b) whether DNF inhibits suspend during operation or $scary_consequences? - *broken* during downloading packages c) whether Rhythmbox inhibits suspend when playing music? - *works*d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? - *broken*f) whether Nautilus inhibits suspend while copying files (possibly to even a remote location)? - *works*
On Mon, Mar 19, 2018 at 2:36 PM, Kamil Paral kparal@redhat.com wrote:
On Mon, Mar 19, 2018 at 1:48 PM, Kamil Paral kparal@redhat.com wrote:
On Thu, Mar 15, 2018 at 10:46 AM, Kamil Paral kparal@redhat.com wrote:
For example, has anyone tested:
a) whether downloading files in Firefox will inhibit suspend or the downloads will be aborted during progress? b) whether DNF inhibits suspend during operation or $scary_consequences? c) whether Rhythmbox inhibits suspend when playing music? d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? e) whether Pitivi inhibits suspend while rendering video? f) whether Nautilus inhibits suspend while copying files (possibly to even a remote location)?
Here's another "broken" use case that we found today: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/18
Currently there seems to be no (graphical) way to disable auto-suspend system wide. Which means the system will auto-suspend regardless of your settings when you perform user switching. It's somewhat unintuitive that suspend, as a system-wide action, is considered a per-user setting (the active user overrides all inactive users), and there's no option to set it system-wide.
Here's even a "funnier" case. The system suspends when you connect over SSH (the system shows a GDM screen locally), even if you're active (running commands). And you can't do anything about it, because it ignores your settings and uses the system default (20 minutes timeout).
So, if you sometimes start your system remotely and ssh in, or if you have graphical issues and need to debug it over ssh, or in any other case that you can imagine when you need to ssh in... your system *will* suspend in 20 minutes. I think advanced users will eat us alive.
What's even worse, there's no obvious way to disable this even for those advanced users. There's no config file in /etc you could edit and adjust. "sudo gsettings" (for setting the right key globally) fails with an error. How do GNOME devs expect users to configure this? What do we tell them? Or is ssh a no longer supported use case on Workstation?
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On 03/19/2018 09:32 AM, Frantisek Zatloukal wrote:
d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? - broken
I've reported a bug for this one: https://bugzilla.gnome.org/show_bug.cgi?id=794485
On Mon, 2018-03-19 at 15:32 +0100, Frantisek Zatloukal wrote:
b) whether DNF inhibits suspend during operation or
$scary_consequences? - *broken* during downloading packages
I suspect this is intentional. dnf probably intentionally only inhibits suspend during parts of its operation where suspending would actually be dangerous. it's not dangerous to suspend during package download (worst case, one download has to be restarted on resume).
of course, they may have made a different choice if this 'default auto- suspend' had been happening at the time.
On 03/19/2018 08:36 AM, Kamil Paral wrote:
What's even worse, there's no obvious way to disable this even for those advanced users. There's no config file in /etc you could edit and adjust. "sudo gsettings" (for setting the right key globally) fails with an error. How do GNOME devs expect users to configure this? What do we tell them? Or is ssh a no longer supported use case on Workstation?
It's definitely supported, this is just a bug... albeit, a nasty bug I have no clue how we should fix.
Try setting a password for the gdm user, log in on a console, and use gsettings there. Does that fix it? Probably?
Can you report another separate issue for this?
On Mon, 2018-03-19 at 09:48 -0500, Michael Catanzaro wrote:
Try setting a password for the gdm user, log in on a console, and use gsettings there. Does that fix it? Probably?
Isn't this kind of a common issue? I think there's actually a doc about it somewhere (probably the Alternative Fedora Wiki, that is, the Arch wiki). There are various reasons you might want to set something in gsettings for gdm, not just this; the one I've always run into before is monitor configuration (telling it my monitors are rotated).
On Mon, Mar 19, 2018 at 3:48 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On 03/19/2018 08:36 AM, Kamil Paral wrote:
What's even worse, there's no obvious way to disable this even for those advanced users. There's no config file in /etc you could edit and adjust. "sudo gsettings" (for setting the right key globally) fails with an error. How do GNOME devs expect users to configure this? What do we tell them? Or is ssh a no longer supported use case on Workstation?
It's definitely supported, this is just a bug... albeit, a nasty bug I have no clue how we should fix.
Try setting a password for the gdm user, log in on a console, and use gsettings there. Does that fix it? Probably?
Can you report another separate issue for this?
I've reported the issue as: https://bugzilla.redhat.com/show_bug.cgi?id=1558485 so that I could nominate it as a prioritized bug.
The solution could be either to implement it as a global system-wide option that only admin users can set and it applies system-wide (all users, gdm), or keep it as a per-user option but allow admin users to configure the global value as well (the same way regional settings can be set for the "logging screen"). Even the same paradigm as with regional settings can be used (which I'm not very fond of, but whatever) - when there's only a single user configured on the system, the option looks like local, but affects the whole system, and when multiple users are configured, it splits into local and global option.
On Mon, Mar 19, 2018 at 9:37 AM Kamil Paral kparal@redhat.com wrote:
On Mon, Mar 19, 2018 at 1:48 PM, Kamil Paral kparal@redhat.com wrote:
On Thu, Mar 15, 2018 at 10:46 AM, Kamil Paral kparal@redhat.com wrote:
For example, has anyone tested:
a) whether downloading files in Firefox will inhibit suspend or the downloads will be aborted during progress? b) whether DNF inhibits suspend during operation or $scary_consequences? c) whether Rhythmbox inhibits suspend when playing music? d) whether gnome-disks inhibits suspend while operating on devices (e.g. writing a disk clone, or checking SMART)? e) whether Pitivi inhibits suspend while rendering video? f) whether Nautilus inhibits suspend while copying files (possibly to even a remote location)?
Here's another "broken" use case that we found today: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/18
My comment on this issue is: disabling auto-suspend != inhibiting suspend.
Currently there seems to be no (graphical) way to disable auto-suspend
system wide. Which means the system will auto-suspend regardless of your settings when you perform user switching. It's somewhat unintuitive that suspend, as a system-wide action, is considered a per-user setting (the active user overrides all inactive users), and there's no option to set it system-wide.
Here's even a "funnier" case. The system suspends when you connect over SSH
(the system shows a GDM screen locally), even if you're active (running commands). And you can't do anything about it, because it ignores your settings and uses the system default (20 minutes timeout).
So, if you sometimes start your system remotely and ssh in, or if you have graphical issues and need to debug it over ssh, or in any other case that you can imagine when you need to ssh in... your system *will* suspend in 20 minutes. I think advanced users will eat us alive.
I think you are dramatizing this a bit. systemd-inhibit will work just fine in your ssh session, I believe.
What's even worse, there's no obvious way to disable this even for those advanced users. There's no config file in /etc you could edit and adjust. "sudo gsettings" (for setting the right key globally) fails with an error. How do GNOME devs expect users to configure this? What do we tell them? Or is ssh a no longer supported use case on Workstation?
The proper way to handle this is for ssh to register its sessions properly. But past attempts to make that happen (back in the ConsoleKit era) were met with total disinterest from the ssh side...
desktop@lists.fedoraproject.org