Yes /etc/ → /etc/systemd/.
1 Like
Hi George,
SSH connections do not prevent system kill on my F38 system. While I commend you for your interest in reducing your electricty use, some of us are also focused on using computers for the tasks that they were able to accomplish in the past. F38 took us back a step or three in terms of usability. Worse, the Devs seem to have no idea how systems are used and make incorrect decisions as a result.
Plus, this whole notion of ‘certification’ as an excuse seems to be bogus. I’d like to hear the details of exactly which certification was issued as a result of this highly intrusive and disruptive change.
Dale
I would like to spend two words on this thread.
I think that we should keep in mind at least two kind of users: power users like the majority of people that are participating in this thread and the rest of the world 
I think that introducing this behavior (ok, It should have been publicized a little more) is perfectly fine for the rest of the world.
For instance in this case, users like that are power users. It is supposed that they know what to do, or at least they are capable to find the answers in order to change the defaults that someone else decided to arbitrarily [1] put in place.
During the pre-release phase of Fedora Linux 38 I incurred in this issue as well. I didn’t understand why my PC was going to sleep even if I didn’t change anything, suspecting that it was a bug. I asked that in some Fedora Chat channel, I don’t remember, and turned out not to be a bug. And now that I’m aware of this behavior, I have no problem. On my laptop I leaved it as is. On my desktop I disabled automatic suspend. Done.
please note the italic typeface; in fact, at first instance, I always think there are good intentions behind the choices, like in this case ↩︎
3 Likes
I understand that you’re upset, but: Really. Please stop with this kind of accusation. It doesn’t help anyone or anything.
Fedora does everything we can transparently and in the open. You can find the Workstation team’s discussion on this linked from the Common Issues topic that this topic is connected to. That discussion was prompted by a request from an engineer at Lenovo. You can follow that thread back to previous discussion, which will eventually lead you to:
EU Commission Regulation No 801/2013, amending Regulation (EC) No 1275/2008.
and
ENERGY STAR Product Specification for Computers, Eligibility Criteria Version 6.1 Rev. March-2016
There’s no conspiracy here.
Hi Matthew,
I am sorry if my strongly stated opinions caused you or others some heartache. It is not my intent to cause hard feelings.
My intentions are to highlight a couple of significant failures in the process that Fedora uses to add ‘features’ to the product we all use and like, Being transparent is a great idea but only truly works if everyone can see what is coming up. Transparency is also admitting that the process failed and talking about how to prevent failures like this one from occurring again.
Thanks for the pointer to the initiating thread. I’ll read that and then come back with my conclusion. However, I stand by my assertion that a software change cannot achieve certification except on a specific piece of hardware that is also included in that certification process. So, maybe this helped the Lenovo folks, but it caused damage to the rest of us.
To Alessio, you may be right that the people here are involved enough to actually question what happened and work out private fixes for these design errors. So far, I have not seen anything about this issue being added to a 'known issues document in Fedora 38. That document seems to have been eliminated in favor of this discussion group, which will result in the issue falling off the first screen when people get tired of talking about it.
I had a non-involved friend install F38 and complain to me that his computer was powered off whenever he went to use it. It turns out that he was logging off each time he was finished using it interactively, but his media server and other things were still running. They were killed when the system power was pulled. Not good.
Dale
Yes you right, my mistake. As I know from other .conf files, it not depends how you name them. Just name them so that you see what they do. I will observe and give feedback.
When writing them direct in the /etc/systemd/sleep.conf file you will loose the config if something different gets delivered.
I changed it above. Thanks.
This thread is a companion to the topic in the curated Common Issues category. Topics stay there as long as they are relevant. Those which are resolved or which only apply to old releases are kept in Archived Common Issues.
1 Like
Just to clarify, are people having ssh session close while actively using them?
My experience (using an older iMac so may not have the same power management as newer hardware) is that the workstation does not suspend while the SSH session is being used. If I’m dealing with other demands on my time and don’t do anything in the ssh session for some time (I assume 15 minutes), the workstation goes to sleep. I use wake-on-lan and then start a new ssh session.
Yes, all SSH sessions are closed. I wrote about it few post before.
Still not clear. For me, ssh sessions close if I’m not actively using them, but I have not had a session close when actively entering commands, or editing in emacs. I haven’t timed it,
but 15 minutes without any keyboard input seems about right, and it takes very little effort to start a new session after wake-on-lan.
Let me explain the behaviour I experience.
One (o more) SSH sessions open.
Working on the sessions with keyboard (and network traffic) activity
15 minutes later, puff…computer shuts down.
Then, a new test:
- computer power up and running
- SSH sessions open
- While using the SSH sessions, I kept pushing some keys on the console keyboard (at the login screen)
- no shutdown after 15 minutes
- I stopped pushing keys on the console keyboard
- 15 minutes and the computer shuts down
Clearly the power settings (GDM or otherwise) are ignoring any network traffic.
Agreed.
What percentage of users of Fedora are ‘Power Users’?
I suspect that there are a significant percentage of users that fit that category and thus directly are impacted by the change.
I am not upset that the change was made since it seems it was a result of good intentions and likely has an overall energy saving impact. I am frustrated that it was done with little widespread advance notification and it seems many were impacted.
Maybe plans could be made for something like a fedora magazine article or other quite public notification to inform users of upcoming changes that might impact usage as this change has done.
2 Likes
I think we need to distinguish between outgoing ssh sessions and incoming ones. As long as you’re active at the local keyboard, that should be no problem. It’s the other way that is a concern. (See Can Fedora Workstation be configured so SSH logins inhibit suspend?)
It’s really hard to measure — especially since power users are the most likely to be active in messaging and even in answering surveys. I agree that it’s a significant and important part of our userbase and community, no matter the numbers.
That said, I don’t think this particular issue is so clear-cut. I consider myself a power-user, and have one workstation I’m glad to have power off,[1] and another one which I’m running Home Assistant on, and definitely don’t want to — but, also, I really should move all that to a more low-powered device and I let that one sleep to.
Absolutely — that’s exactly the sort of thing that we try to do as part of the Changes process.
and irritated that Steam blocks that, actually ↩︎
1 Like
Let me explain the behaviour I experience.
- One (o more) SSH sessions open from a remote computer into the computer running FC38
- Working on the SSH sessions with remote keyboard (and network traffic) activity. Why is this relevant? Because KBD activity generates input to the pseudo tty devices in the FC38 box.
- 15 minutes later, puff…FC38 computer shuts down.
Then, a new test:
- FC38 computer power up and running
- SSH sessions open from remote computer into the FC38 computer
- While working in the SSH sessions (from the remote computer), I kept pushing some keys on the FC38 console keyboard (at the login screen)
- no shutdown after 15 minutes
- I stopped pushing keys on the FC38 console keyboard
- 15 minutes and the FC38 computer shuts down
Clearly the power settings (GDM or otherwise) are ignoring any network traffic.
I was startled by this new behavior in F38. And this was on systems upgraded with DNF, not fresh installs. Not cool. But so much for the past.
Several of my machines that run fedora-workstation offer services.
I know how to turn off suspend-after-inactivity per user plus GDM. I would l like a global setting since this is a global policy issue.
I understand that the fedora-server has the suspend-after-15 turned off. Is that a global setting? Is that something that we could be told about?
If not, I request a global setting. One that applies for all Desktop Environments, not just GNOME.
Networks are chatty, so you if you don’t ignore network traffic you won’t suspend.
Expect the unexpected when upgrading. Linux, Windows, and macOS all have the problem of communicating changes to users when new versions are released. There are usually lots of changes, too many for users to keep up, and many users wouldn’t know which changes affect them.
I approach upgrades cautiously by installing the update on an external drive and looking for issues before upgrading the “mission critical” systems.
1 Like
I often use ssh from a laptop into my F38 desktop (and old iMac) located in an outbuilding. It usually needs wake-on-lan before I can connect with ssh. Then I can use ssh for much longer than 15 minutes. The laptop suspends if I stop working, and when I get back the ssh session has often closed. My server never suspends, but idle ssh sessions also close after a period of inactivity. There are configuration options (man sshd_conf) that control what happens a client is non-responsive. I use the defaults. Something has changed, as today I have been away from the desktop for hours and just connected from the laptop without needing wake-on-lan.
I am not sure which you are referring to as the ssh client. In normal terms your laptop would be the ssh client and the workstation (server) would be the sshd server. When the client suspends it would always disconnect the ssh session from the server. If the server suspends it also would disconnect the client.
However, you mention wake-on-lan and I suspect you are meaning that the laptop is waking the server up, which seems to imply the server has suspended.
The laptop suspends when idle – seems to be related to this change we are referring to .
The workstation (server) needing to wake up with wake-on-lan also seems related to this change.
hello can you help me here ?