I would love to see reliable suspend support on all hardware. In fact, personally, I haven't had any significant troubles with suspend in many years. I would even love to see time-based autosuspend as a reliable feature. But I very much doubt that autosuspend a viable default for Fedora Workstation now.

Apart from the obvious issues with possible bugs and the luck of resources to handle them effectively, I think there are bigger questions about how desirable this would be. Autosuspend is great in the server-client model, where the machine is just a glorified display panel and can go away and come back at any time. But it is incompatible with various ways that people use Fedora. A few things that I do, that would break: background computation tasks, including mock builds, fuzzers, movie conversions, ssh sessions, irc sessions. I'm sure that there are many other examples. Those are all things that a normal Windows user does not do, but which are possible and expected here, and which imho must be taken into consideration.

It is possible to inhibit suspend, but the user interfaces for this are not very nice. I think that as a prerequisite of enabling suspend by default, we should make the way that this can be disabled and/or inhibited more discoverable:
- the dialogue to configure autosuspend is nice and straightforward, but it is buried in the power settings, so one needs to look for it to find it. It'd be great if after the first autosuspend a notification popped up "This machine was automatically suspended based after 20 minutes of inactivity. This can be disabled and the time adjusted in <settings>", where the <settings> would take the user straight to power settings.
- there is no way to inhibit suspend graphically. I use https://extensions.gnome.org/extension/517/caffeine/, but if we enable autospend by default, some pluging or a built-in mechanism should be available by default.
- command-line inhibition through systemd-inhibit is possible, but the man page is not that great, and it's a very low level tool. If we think people should use it more widely, the documentation should be enhanced with examples and a high-level description.

Then there are use expectations. I think that the general understanding until now is that: on AC power, the machine never goes away, and on battery, it stays around while there is power, but will automatically hibernate at some point. The expectations for behaviour on battery and on AC are quite different.

To summarize: my recommentation would be to disable autosuspend in F28, and for F29, make it a visible Change, with enhancements to tooling and user interface and documentation to make it easy for users to override.

My concerns are not related to the fact that we now have autosuspend by default (even on AC), but that the current implementation has a lot of very rough edges:

• Removing a suspend inhibitor doesn't reset the timer, and thus your computer suspends immediately e.g. after a movie you've been watching (in a movie player or web browser) has finished. bug 1, bug 2, PR (I'm not sure whether that PR fixes both X11 and Wayland or just Wayland)

• There are high profile apps which were not adjusted to have suspend inhibiting in mind (because it was a very niche issue in the past, now it affects everyone), like downloading files in Firefox or performing disk operations with udisks (there are probably a ton of more, we tested just a few apps).

• There is no user friendly (graphical) way to configure a system-wide behavior (bug 2), only the behavior for your particular user session. That means that your system will autosuspend any time it is in GDM and users can't do anything about it without deep technical knowledge. This includes use cases like: fast user switching, accessing shared files or logging in over ssh. Technical users can adjust this, provided they find this documentation.

• Multi-seat has been completely broken by this.

• Some desktop environments, like Fluxbox, which are using GDM as a login screen, don't work properly with this new setting, and the system suspends immediately after logging out.

• This feature is not exclusive to Fedora Workstation, but also affects other editions, like Fedora Server. If you install GDM to Server, because you prefer to configure some things graphically (which is not uncommon for many sysadmins), your server will start autosuspending after 20 minutes.

I'd recommend having these issues fixed or improved before setting the autosuspend by default. Or at least use autosuspend just on battery for now (where such behavior is more expected), but not on AC. As a piece of interesting information, Ubuntu has already done this (overrode the default and disabled autosuspend on AC).

Worth to mention, there's also a related issue of autosuspend now being enabled even on Fedora Workstation Live image, which I consider a very risky gamble with no clear benefits. One of our machines is known to fail to resume when running from an external optical drive. It sure won't be the only one in the world. Even more problematic are in my view the expectations. People use Live images to system debugging, fixing broken systems, recovering data or creating backups. They don't expect the system to suspend in the middle of a dd or fsck operation. Yet it will. Coincidentally I used F28 Beta Live image to back up and restore my disk image last weekend, and I felt like operating in a minefield. I must have taken extreme care to always disable autosuspend after each Live boot, because otherwise my dd | nc operations would fail and I would have to start again (in the better case; for some operations I could have ended up with a silently corrupted data or something, hard to guess). Regardless of all this, the Workstation team insists the Live image delivers the "same experience" as the installed system (i.e. autosuspend enabled).

This will be discussed at the 2018-04-06 FESCo meeting.

Ping @mclasen @adamwill @labbott

You were referenced above and may wish to attend the FESCo meeting tomorrow to express your opinions.

I'm very sympathetic to @kparal's comments above, and would personally love to see more focus on the edge cases before making suspending the default. I'd also strongly recommend not enabling suspend on the live images.

why is this a fesco ticket ? this is in the domain of the workstation sig, as far as I'm concerned...

And for the record, Workstation WG is already considering the issue,
https://pagure.io/fedora-workstation/issue/42

Until that's resolved, imo, it is premature for fesco to become formally involved.

openSUSE has been carrying a downstream patch for at least half a decade or so that does this: https://build.opensuse.org/package/view_file/GNOME:Next/gnome-settings-daemon/gnome-settings-daemon-notify-idle-resumed.patch?expand=1

Sorry, I meant to quote @zbyszek's request for a notification after resuming from idle suspend.

@mclasen as @kparal wrote above:

This feature is not exclusive to Fedora Workstation, but also affects other editions, like Fedora Server. If you install GDM to Server, because you prefer to configure some things graphically (which is not uncommon for many sysadmins), your server will start autosuspending after 20 minutes.

At this point, it stops being a Workstation-only concern and starts becoming a distro-wide concern. Though, I will note that this does not rule out the possibility of making it impossible to install GDM unless the system was installed as Workstation, but I suspect that's not what the Workstation WG would prefer.

For the record, regardless of how inadvisable it might be to have a full GUI environment on a server, many users do this anyway for ease of administration if they have to get into the box. Or because some application they're running on their server requires a graphical installer or configuration tool. I'd prefer not to have to tell them "Oh, you should use XFCE/LXDE/KDE/etc. because GNOME will break your server". That's not a good story for us as a Project.

openSUSE has been carrying a downstream patch for at least half a decade or so that does this:

Thanks for the link. This is useful, although I think it'd be great to add information how to turn this feature off in the notification.

Only the first line of the notification is going to be visible in the tray once it has been displayed, and even that gets truncated to a short length, so that doesn't really seem practical.

Hmm. Indeed. I wish there was a way to include additional information in notifications. Truncating at fixed length without a way to expand seems to be a problem already:

I'd like to add that this change will affect all our users who upgrade, not just new installations. For anyone who hasn't touched the settings in the past (i.e. kept autosuspend disabled) this will change to autosuspend enabled in 20 minutes after they upgrade to F28. This might be quite a surprise for many (reading the discussions around the web, it has already been).

I would like to mention developer use cases here too (as Fedora Workstation is used by many developers).

Developers leave long running processes (like compilation) running and expect them to finish when they get back from lunch / coffee break. The suspend blocking is probably not going to be implemented into for example GCC or command line encoding tools like lame, ogg or even Audacity. I expect this use case is a prime candidate for disabling the auto-suspend feature completely, but the setting seems to be pretty well hidden.

Kamil already said this also affects SSH based sessions, but I guess that can be handled in logind or so (do not suspend when ssh session is active). Some desktop (power-)users are also using software like znc (irc bouncer) or share a nfs/samba folder or printer for their colleagues.

The whole point is.. auto-suspend should be disabled by default and easy to find and configure so people who want it and need it can easily enable it to be in compliance with the EU regulation. Enabling it instead and detecting all the corner cases is so hard for everybody (both developers and users) that it probably is not worth it.

Btw, do not forget that laptops have lid and auto-suspend + lock on lid close is already enabled by default. Laptop users expect it and know how to use it when they leave the machine unattended or when their meeting ends. That alone should be enough for many cases.

@mclasen as @kparal wrote above:

For the record, regardless of how inadvisable it might be to have a full GUI environment on a server, many users do this anyway for ease of administration if they have to get into the box. Or because some application they're running on their server requires a graphical installer or configuration tool. I'd prefer not to have to tell them "Oh, you should use XFCE/LXDE/KDE/etc. because GNOME will break your server". That's not a good story for us as a Project.

So, you are effectively saying: "Sorry, but any of the packages that make up the edition that you are supposedly in charge of can be installed on a server too, so the defaults have to be suitable for a server." I don't see how we can produce anything that is not just the status quo of 'fedora as it has always been' under such constraints.

Ftr, you could just tell those folks: "Oh, you are comfortable with running scripts, being a server admin, right ? Here is the two lines of shell script you need to run to convert the gdm install to server-suitable settings. And if you need further help, here is the link to the sysadmin guide that explains it in more detail"

Replying to @mclasen's comment above, the Server vs Workstation defaults issue should be easily fixable by having different defaults. We could have a global default that let's say disables autosuspend, and then a Workstation override that enables it.

(I'm not taking any sides here with what should be the default for Workstation, haven't read up on all the email thread yet.)

• Due to lack of quorum, FESCo will wait until next week to gather more information and make a decision. (sgallagh, 15:36:31)
• FESCo will currently leave this decision for the Workstation WG, as long as a method not to impact Server is determined. (sgallagh, 15:44:30)
• sgallagh and mclasen will meet next week to discuss mitigations for Server (sgallagh, 15:44:43)

For upgrades, we could add an upgrade script that touches the setting to keep it from getting flipped for existing users. It makes sense that this change should probably only affect new installs.

So, you are effectively saying: "Sorry, but any of the packages that make up the edition that you are supposedly in charge of can be installed on a server too, so the defaults have to be suitable for a server." I don't see how we can produce anything that is not just the status quo of 'fedora as it has always been' under such constraints.

It's really a matter of issue severity... it's pretty bad if installing a package causes your server to unexpectedly suspend itself when you don't have physical access.

For upgrades, we could add an upgrade script that touches the setting to keep it from getting flipped for existing users. It makes sense that this change should probably only affect new installs.

Actually that's not as easy as I was thinking, since it's a user setting.

Developers leave long running processes (like compilation) running and expect them to finish when they get back from lunch / coffee break. The suspend blocking is probably not going to be implemented into for example GCC or command line encoding tools like lame, ogg or even Audacity.

We might want to make sure the terminal takes a suspend inhibitor when a command is running.

We might want to make sure the terminal takes a suspend inhibitor when a command is running.

But then you have tools like Midnight Commander and tmux that by themselves should not block suspend. On the other hand, a command might be running inside of those. Ideally you would need some kind of suspend decision delegation mechanism, but I have never heard about anything like that and you would hit the not implemented there issue again.

Btw, some tools I mentioned are fine with screensaver activation, but not with suspend. And I am not sure even systemd-inhibit separates those two as the manpage is not exactly clear about what is based on idle timer.

Hello, I'm currently an external consultant at the European Commission - so I can't speak to this with any authority as I'm not legally allowed...BUT - I think (in my opinion) that this decision is being made based on an incorrect interpretation. Fedora is software - not hardware. Hardware vendors are obligated to follow this rule. Is software without hardware required to set defaults like this across all ranges of hardware that they may or may not actually be installed on? Good question.

Before making a decision on an EC directive that will negatively affect a certain class of users (namely server/workstation admins), I suggest getting a clarification. This can be accomplished by writing a letter to Commissioner Bienkowska explaining the question and need for clarification. The policies dictate a response within 15 days. Contact details are here - https://ec.europa.eu/commission/commissioners/2014-2019/bienkowska/team_en - please let me know if I can be of any assistance in this inquiry.

In today's Workstation WG meeting, they made the following decision:
"Workstation WG discussed the new auto-suspend behaviour and decided to disable auto-suspend for F28. In rawhide (F29) we'll enable auto-suspend when battery powered only, and disable when plugged in."

From my perspective as Server WG representative, both the F28 and F29 plans resolve this issue for us, so I propose that this issue be dropped from FESCo's agenda and left to the Workstation WG to handle.

Agreed. As this week's chair, I'll take the liberty to drop the meeting tag and close this.

@panikal thanks for the advice and the offer to help, but I think we're good.