PDA

View Full Version : How to Enable/Disable Power Mgmt while Running a Script? dbus?



bob p
8th November 2014, 03:29 AM
I'm using the KDE on F20 / F21. In KDE System Settings > Power Management > Energy Saving, I have Screen Energy Saving set to blank the screen after 15 minutes of inactivity, and to Suspend Session configured to suspend the box to Sleep (S3) after an hour of inactivity. Works like a charm. If I need to access the box remotely, I'm able to use a WOL script to wake up the box prior to initiating an SSH session.

I'm having a problem with the KDE power management settings causing problems during a scripted event. I have a BASH script that I need to run via cron, which in turn spawns a Python script that can take several hours to run. At present, I'm having compatibility problems with KDE's power saving settings, which suspend the box to S3 while my BASH/Python scripts are running, because KDE's power saving daemon only monitors keyboard and mouse activity, and not CPU load factor, LAN activity or disk activity, when making the decision about whether or not to Suspend to S3.

I'm looking for a way to use scripted command entries to selectively turn-off power management at the beginning of my script (so that KDE will not suspend the PC while the script is running) and to turn-on power management when my process reaches completion (so that KDE can go back to it's normal power management behavior). In other words, I want to keep KDE's screen-blank at 30 minutes and Suspend to S3 at 60 minutes, but I want those events NOT to happen whenever my script is running.

I've tried using OS calls from the script, such as "xset -dpms" and "xset +dpms", but they're not working. KDE power management forces the box into S3 after the kb/mouse timeout, irrespective of the script's activity and the CPU load.

I imagine that turning power management on/off could be managed via dbus, though I'm having trouble finding documentation, as it seems that the dbus commands keep changing and some of them appear to have been deprecated.

I had found a suggestion at the KDE forum, which suggested that this might be a viable option for inhibiting suspension:

site: https://forum.kde.org/viewtopic.php?f=107&t=80118


qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement \
org.freedesktop.PowerManagement.Inhibit.Inhibit

I'd like to ask a few questions about this:

1. is the dbus call still something that is supported, or is it deprecated?
2. if the dbus call to inhibit power management is supported, what's the appropriate dbus command to turn power management back on?
3. can anyone point me to the current dbus documentation?
4. can anyone suggest a better way to do this?

I'm open to any helpful answers that could help me accomplish the goal of not having my PC go to S3 while the script is running I'd prefer to explicitly issue a call that would force power managmeent on/off, rather than periodically issuing a call to fake keyboard or mouse input.

tia.

slopsbucket
8th November 2014, 01:29 PM
I don't know what script you'd need but I do know where you'll find it - Movie Players.

VLC, Kaffeine and the others all lock down power management while the movie is playing and you're not touching mouse or keyboard. When the movie ends power management is reinstated.

First rule of programming - when you come up with an idea for a program check to see if someone else has already written most of it for you.

In this case I believe they have.

Cheers,

Andrew.

Dutchy
8th November 2014, 02:21 PM
Could it be that this is done with the Gnome SettingsDaemon (found via qdbusviewer)?

bob p
8th November 2014, 11:33 PM
dutchy, i really don't know anything about dbus, which is why i asked about documentation. i really need help in that regard.

"qdubusviewer" doesn't work as a command line entry. is that not what you meant?

lsatenstein
9th November 2014, 12:38 AM
I'm using the KDE on F20 / F21. In KDE System Settings > Power Management > Energy Saving, I have Screen Energy Saving set to blank the screen after 15 minutes of inactivity, and to Suspend Session configured to suspend the box to Sleep (S3) after an hour of inactivity. Works like a charm. If I need to access the box remotely, I'm able to use a WOL script to wake up the box prior to initiating an SSH session.

I'm having a problem with the KDE power management settings causing problems during a scripted event. I have a BASH script that I need to run via cron, which in turn spawns a Python script that can take several hours to run. At present, I'm having compatibility problems with KDE's power saving settings, which suspend the box to S3 while my BASH/Python scripts are running, because KDE's power saving daemon only monitors keyboard and mouse activity, and not CPU load factor, LAN activity or disk activity, when making the decision about whether or not to Suspend to S3.

I'm looking for a way to use scripted command entries to selectively turn-off power management at the beginning of my script (so that KDE will not suspend the PC while the script is running) and to turn-on power management when my process reaches completion (so that KDE can go back to it's normal power management behavior). In other words, I want to keep KDE's screen-blank at 30 minutes and Suspend to S3 at 60 minutes, but I want those events NOT to happen whenever my script is running.

I've tried using OS calls from the script, such as "xset -dpms" and "xset +dpms", but they're not working. KDE power management forces the box into S3 after the kb/mouse timeout, irrespective of the script's activity and the CPU load.

I imagine that turning power management on/off could be managed via dbus, though I'm having trouble finding documentation, as it seems that the dbus commands keep changing and some of them appear to have been deprecated.

I had found a suggestion at the KDE forum, which suggested that this might be a viable option for inhibiting suspension:

site: https://forum.kde.org/viewtopic.php?f=107&t=80118


qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement \
org.freedesktop.PowerManagement.Inhibit.Inhibit

I'd like to ask a few questions about this:

1. is the dbus call still something that is supported, or is it deprecated?
2. if the dbus call to inhibit power management is supported, what's the appropriate dbus command to turn power management back on?
3. can anyone point me to the current dbus documentation?
4. can anyone suggest a better way to do this?

I'm open to any helpful answers that could help me accomplish the goal of not having my PC go to S3 while the script is running I'd prefer to explicitly issue a call that would force power managmeent on/off, rather than periodically issuing a call to fake keyboard or mouse input.

tia.


Do you need to run your scripts with KDE? Bash script should be GUI independent.
With Gnome, there is an extension called caffeine, whose sole purpose is to prevent the screen from blanking out and entering sleep mode.

To obtain caffeine, (which only runs with Gnome, as far as I know), you must install
gnome-tweak-tool, search for external extensions, and install caffeine.

Here is another idea.

If you have not done it, you can setup crontab to run your bash script at a certain time.
I left my system running 24/7, and my twice a week crontab entries ran without problems.

As a reminder, the user crontab has very few environment variables, you would have to setup all external mounts and environment variables in your initialization script.

If you need an example, I can send you one.

marko
9th November 2014, 02:51 AM
This poster on stack OF says he got dbus-python to inhibit power management and it worked "perfectly" and
talks about issues with using dbus on the command line to do the same:


http://stackoverflow.com/questions/17478532/powermanagement-inhibit-works-with-dbus-python-but-not-dbus-send

bob p
9th November 2014, 09:50 AM
Do you need to run your scripts with KDE? Bash script should be GUI independent.
In the perfect world that I would like to live in, I could do this in Bash and I wouldn't have to worry about using tricks that are unique to either KDE or Gnome.

In the real world that I actually do live in, the Bash utilities to do this are weak and/or don't work properly and/or I just can't figure out how to get them to work. The result is that we have to restort to KDE trickery like this:

qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement \
org.freedesktop.PowerManagement.Inhibit.Inhibit
or Gnome trickery like this:


With Gnome, there is an extension called caffeine, whose sole purpose is to prevent the screen from blanking out and entering sleep mode.

To obtain caffeine, (which only runs with Gnome, as far as I know), you must install
gnome-tweak-tool, search for external extensions, and install caffeine.

I really DON'T WANT to do this using Gnome or KDE, because my boxes are all configured to boot to a console logon, not to a GUI. I'm concerned that none of these Gnome or KDE tricks will even work if the desktop manager isn't loaded, as in the case when a box is rebooted, a headless server is at work, etc.

Yes, you're right -- It really makes the most sense to do this in Bash, and I'd really prefer to do it that way. I'm really not interested in KDE-based approaches if I can avoid them, as I never know whether KDE may be running on a remtoe box or not. And I'm really not interested in Gnome-based approaches as I'm not using Gnome. As far as Caffeine is concerned, I share your opinion that it's better to use a Bash script than a tool that sits in a system tray on a GUI desktop. Bash should work everywhere, GUI-based tools probably won't be effective if the system is at a command prompt.



If you have not done it, you can setup crontab to run your bash script at a certain time.

That's a good idea, BTDT. Unfortunately, as was noted in the post on StackOverflow that Marko cited, the effects of an inhibit command called from within a Bash script will only survive as long as the lifetime that the Bash script is being executed. When it's process dies, the inhibition dies with it. My experience has been that the cron approach didn't pan out for me.


If you need an example, I can send you one.
ygpm

dobbi
9th November 2014, 11:52 AM
I think but am not sure there is a proc or sys file somewhere that if you echo a value into it will do the trick and be DM agnostic, but "find /sys -name "power" resulted in a long list.

also have you tried xset? or setterm?

http://tldp.org/HOWTO/Battery-Powered/methods.html

Don't know if it overules the DM ones.

Aside from that ACPI, DPMS, APM or something else all have their own ways.

UPDATE Sun 9 Nov 02:19:15 HST 2014

It occured to me that one could use ps aux to look at the processes before one starts and then after to see what the new ones are that have the same name of the target and use that to keep the bash script alive, using a function with a "wait" in there, would that be acceptable ?

marko
9th November 2014, 06:27 PM
Did see my solution I posted in post 6? Just use dbus-python and make a wrapper script for running your long running python script (or if you like you can modify the long running script itself to use dbus-python to suspend power management)

bob p
10th November 2014, 01:48 AM
Thanks, everyone. :)

I mentioned the failure of xset in the first post.

Marko, you're right -- the easiest way to approach this in Python is just to pull-in the existing python code that is known to work. I tried doing that, and it seems to work as intended. I'd really prefer a universal bash method to approach the problem, because I'd like to also use this type of solution with other bash scripts that don't involve python. but at least the python method gives me a temporary workable solution, even though it may not be the universal solution I'm looking for.

The next step is trying to determine how to prevent sleep mode from taking place when I have an active SSH connection. I have that working on older versions of Fedora that use pm-utils, but that method no longer works now that Fedora has replaced pm-utils with systemd.

http://www.forums.fedoraforum.org/showthread.php?t=301440

marko
10th November 2014, 04:04 AM
Another idea for power suspending just before running a script



qdbus org.kde.powerdevil /modules/powerdevil setProfile Presentation
< run script here>
qdbus org.kde.powerdevil /modules/powerdevil setProfile <put usual profile here>
KDE4 usually comes with a pre-defined "Presentation" profile that disables all power management

bob p
10th November 2014, 05:06 AM
I very much DISLIKE the idea of an end-user being forced to put every script that he ever writes inside of a dbus-aware wrapper. That's a giant step BACKWARDS.

The way Fedora used to work, an end user just wrote his scripts and he didn't have to worry about sleep mode. The Superuser just tweaked the sleep-mode scripts on the system to perform checks before it sleep mode was activated, and end-users didn't have to do *anything* special. They could ignore the power management aspects of the system, and just focus on writing their own scripts -- they didn't have to pay attention to the black magic of making their scripts interact with the obtuse requirements of controlling the power management system.

With this new dbus arrangement, it seems that the Superuser can't take care of these problems on behalf of all of his users, thereby allowing end users to focus on their own work. Now every end user has to learn arcane methods of calling power management commands via specialized wrappers that he has to place around every script that he writes. Now every user has to be aware of how to toggle the behavior of a power management system by writing power management-aware scripts. And they have to do this with a power management system that is very poorly documented.

How does that represent a step forward in terms of usability? To me, this is a giant step backwards.


OK, rant is over.


I'd like to point out that I'm no longer seeking a solution for manually turning the power management system on/off before I run a script -- thanks to everyone participating here, we have some really good examples of how to do that.

What I'd really like to know about is covered in that other thread -- how to make the system pay attention to the fact that important connections have been established on the box, and how to pre-empt sleep mode so that it doesn't interrupt SSH sessions, file transfers, etc. IMO this sort of problem needs to be addressed globally at the system level, so that the superuser can make *ONE* administrative change to the system config that imposes compatibility for everyone. It's just not feasible to expect a large number of end users to rewrite every one of their scripts. There has got to be a better way to do this.

ocratato
10th November 2014, 05:30 AM
I agree with bob_p that adding a KDE specific dbus command to scripts is not a good solution. In addition, marko's solution can leave the power management disabled if the script should exit unexpectedly. However, the script does need to have some interaction with the power management system if needs to cause it to not shut down.

Perhaps a better idea would be for a service that could be called by a script that would inhibit power management and automatically re-enable it when the script completes. Probably have three components - a continuously running server process that monitors for completing clients, a process that runs the dbus command to inhibit power management and sleeps until it's killed by the server, and a command to be called by the client to register itself with the server.

marko
10th November 2014, 05:38 AM
Look, I'm not saying my idea was good, it was what I could find. I suppose the main cause of
the lack of well known ways of power control for this is that most of the hosts doing things like ssh connections are critical systems that are just never powered off.

I see that Arch uses systemd and has something called 'sleep hooks' does that mean something?:

https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks

Then I see here:

http://serverfault.com/questions/321499/how-to-disable-all-power-management-in-ubuntu-for-a-server-netbook

in the section "Command line level" they show how a script in /etc/pm/sleep.d ( they show an example 000cancel-hibernate-suspend)
could block or allow sleep/hibernate conditionally. The example script would just need to be changed to have code to detect ssh is active.

bob p
10th November 2014, 06:57 AM
I understand that everyone is just trying to put forward the best solution that they can find. I hope I'm not coming off as being too critical about that. I really do appreciate everyone's input.

With regard to Marko's comment about /etc/pm/sleep.d:

I wrote a great set of scripts to go into /etc/pm/sleep.d, so that I could monitor every type of connection that I did not want a sleep state to interrupt. Testing the scripts, everything worked exactly as expected. The problem was that even though the scripts worked as desgined, they never prevented the sleep state from occurring, because Fedora no longer pays attention to any scripts located in /etc/pm/sleep.d. The sleep process completely ignores anything in /etc/pm/*, as pm-utils has been deprecated, and replaced with systemd. This goes all the way back to F15 or F16. As a result, looking at solutions from other distributions that still utilize pm-utils isn't going to help much. :(

Those Arch references look interesting. Hard to follow, but interesting. Fedora really needs to come up with some decent documentation. None of this is even addressed in the F20 Power Management Guide:

https://docs.fedoraproject.org/en-US/Fedora/20/html/Power_Management_Guide/index.html

sea
10th November 2014, 12:17 PM
The pm-command still work.
I'm wondering what qdbus is?

Is it something like dconf-editor or gconf2-editor?
With one of these, there comes gsettings, whith which one can change values easily.

Here's a short example to change some pluma/gedit settings.

# Pluma Settings
cmd="gsettings set org.mate.pluma "

$cmd print-line-numbers 0
$cmd max-recents 10
$cmd color-scheme cobalt
$cmd toolbar-visible false

for T in auto-ident bracket-matching enable-search-highlighting enable-syntax-highlighting highlight-current-line statusbar-visible
do $cmd $T true
done

This said, you can disable the power saving at the start of your script, and re-enable before the scripts ends.
Where the location of the power saving is.. i dont know.

Hope this helps

EDIT:
To easy browse the path of the settings, use dconf-editor.
To get a specific value, use: gsettings get org.path.to.settings

bob p
12th November 2014, 01:02 AM
I filed a bug against the F20 Power Management Documentation in relation to this issue. I thought that the ability of a sysadmin to interrupt/inhibit the sleep process was germane to the discussion of power management in Fedora, and this type of information remains conspicuously absent from the official documentation.

Much to my dismay, as soon as the bug was filed, one of the assigned developers immediately removed himself from the CC list. I guess he wasn't interested.

bob p
20th November 2014, 02:36 AM
So I've been tinkering with this for another week or so... not much luck.

What is a real PITA is that the only good methods for performing the enable/disable of power management all seem to bee based upon methods that get introducted by the X11 display manager. There are KDE / Gnome methods of doing this, but they all explicitly require X11 to be running. If you try to run the scripted commands on the box when the window manager is not loaded, the result is a no display error.

It would be a lot simpler if there were direct handles to the OS, rather than having to go through a window manager, which may or may not be in use. Aargh.

marko
20th November 2014, 04:34 AM
This is a guess but what happens if you do:




systemctl stop upower.service

do whatever here you don't want power interrupted on

systemctl start upower.service

The "systemctl list-units" command shows that upower.service is the "Daemon for power management", it would see
logical that stopping it would stop the system from suspending?

bob p
20th November 2014, 05:28 AM
Interesting idea.

I took a look at "man upower" and it isn't documented well at all. The man page says that writing of the manual is still on the developer's to-do list. I guess we have the blind leading the blind now. ;)

I tried using "upower -e" to enumerate the object paths for devices and this is what I got in response on a machine that had KDE Running:


# upower -e
/org/freedesktop/UPower/devices/mouse_0003o046DoC52Bx0004
/org/freedesktop/UPower/devices/DisplayDevice

When I tried running the same query on on a machine that didn't have X11 running, I got a null response. To me it looks like the upower daemon is also dependent upon X11, so I'm really no closer now than I was before, when I poked the KDE screensaver timer on a box that was running KDE. Getting the sytsem to work in the absence of an X11 display manager is still the problem..


An additional problem that comes up is that turning daemons on/off typically requires root privileges. I'm really trying to avoid the situation where someone has to have superuser privileges just to make sure that their cront job won't be interrupted by a snooze event.

There's got to be a way to do this without giving everyone sudo privileges.

bob p
19th September 2016, 10:27 AM
I hate it when I search for a solution to a problem, and the only hits that I find are the threads where I've been banging my head on the desk trying to solve it. :dis:

I'm resurrecting this necrothread because I'm having problems again. I've upgraded to F24 and the scripting system that used to inhibit the sleep state has stopped working and I haven't been able to determine why it stopped working, or how to get it working again.

My problem is this: I have processes that run either in terminal windows or in cronjobs that interact with other machines on the network. When one of these processes is active I need to inhibit entry to the Suspend/Sleep state on my desktop PC.

My desktop PC has a Bash script that runs in a cron task every 10 minutes. It uses netstat to determine if there is traffic on certain key ports (such as port 22 for ssh activity) and uses "ps ax" and grep to determine if certain key processes are active. If any of the desired activity is recognized, then the Bash script issues the following dbus command to prevent entry to the sleep state:


/usr/bin/dbus org.kde.screensaver /ScreenSaver SimulateUserActivity > /dev/null 2>&1

I understand that when my bash script terminates, the effects of any inhibition should also terminate when the bash script terminates. I had been simulating user activity to reset the screensaver timeout because this was an exception to the rule that inhibition would cease with exit of the bash script. By resetting the screensaver timeout, simulated user activity would successfully prevented the sleep state.

Now that I've upgraded to F24 it no longer works.

Anybody?

DBelton
19th September 2016, 03:30 PM
Try looking at systemd-inhibit That is what it's purpose is :)

I guess you could run it from a script.

Edit:

man systemd-inhibit

Also found this reference. Don't know if you can find anything useful in ot or not.

https://www.freedesktop.org/wiki/Software/systemd/inhibit/

bob p
19th September 2016, 09:27 PM
I appreciate your links to the systemd-inhibit documentation page and the manual page. Unfortunately, those two pages both provide scant information about implementing the system, and where they fail to provide a complete explanation they direct the reader to one another as cross references. That reminds me of a deadly embrace.

I was aware of that information back in 2013 (last time the freedesktop.org page was updated). I ended up not using systemd-inhibit locking as described on that page for a few reasons:

1. The freedesktop org documentation is incomplete. In both cases, the incomplete documents point to one another for further explanation, but neither one contains any more content than the other.

2. The Fedora documentation is incomplete. Years ago I filed a bug report against the Fedora documentation, which is the prescribed way to complain about this problem, and nobody cared enough about it to do anything. For several years. Obviously, the Fedora documentation writers don't think this is important enough to address.

3. The systemd-inhibit protocol is an inordinately complex solution to a simple problem. Looking at the documentation you can see that it's quite a pain in the ass to implement, and scripting requires creating obfuscated wrappers around every task that you want to perform. In my case it creates the burden of forcing a n administrator to rewrite hundreds of scripts with wrappers just to inhibit sleep. does anyone actually think that is a plausible solution?

4. The systemd-inhibit protocol requires re-writing an unlimited number of scripts at the user/application level, rather than centralizing control of the sleep state at a level controlled by root.

in addition to de-centralizing control from root to users, now the number of steps that need to be taken is multiplied by the number of user processes involved, such that each user/process/script is burdened with the obligation to perform systemd-inhibit-compliant requests to inhibit sleep. Once again, this procedure fails conceptually, as it de-centralizes the task of performing sleep deprivation and redistributes the work load from one overseer/process to potentially hundreds of independent processes. Instead of having one overseer (root) manage the system, now we have an unlimited number of individual user processes that have to jump through hoops.

Does anyone actually think this implementation was intelligent? It would seem that the people who designed this methodology live in a world where computers are limited to providing a GUI in a single user environment and no task is more complicated than a desktop user trying to burn a CD.

5. The concept of having root just kick the screensaver timeout is orders of magnitude more simple to implement. In my example, I just have root perform a survey of the ports that are in use, and kick the screensaver timer to prevent sleep. Doing it this way, the root user can take ONE STEP to prevent sleep execution on behalf of every user/process, rather than requiring each user (and each user process) to submit to Byzantine wrapping for every task in every session.

If simple is better, then systemd-inhibit is a colossal failure.

Of course, I'm just griping at this point, and I don't want this griping about systemd-inhibit to shift the attention away from the real question that needs to be answered:

Why does the simulation of user activity via dbus no longer works as intended? This should work -- in fact it used to be the recommended way of performing this type of action via dbus -- but now it doesn't work. I'd really like to know why:


/usr/bin/dbus org.kde.screensaver /ScreenSaver SimulateUserActivity > /dev/null 2>&1






Thanks for your attempt to help.

DBelton
19th September 2016, 10:15 PM
Actually, pretty much all you should need to do would be to wrap your script in systemd-inhibit.


For example, if you want to run "script-a"

systemd-inhibit script-a

Taking the defaults it inhibits system sleep, shutdown and idle while it runs the script.

also, systemd-inhibit can be run by a regular user or root.

bob p
20th September 2016, 02:35 AM
Thanks again for your help. For those scripts that are run in cron tasks, it would seem simple enough to prefix them with the instructions that you've recommended. That's not overly burdensome, as the cron editing only needs to happen once, and the tasks can be repeated on schedule without additional user intervention.

I have another question and the burden that these new "enhancements" place on end-users.

1. Suppose that a user wants to ssh into a remote host, and the sysadmin wants to configure the system so that suspend/sleep states on the system don't terminate a user's ssh session. Is there a way for the administrator to automate this, so that the system is smart enough not to squash user sessions? Or does the burden fall upon the user to wrap every console command with systemd-inhibit every time that he executes an ssh session? In the instant cases, I'm seeing the system go to sleep during the middle of file transfers, just because systemd is only paying attention to the keyboard and mouse, and completely ignores network traffic and cpu utilization.

In order to prevent this problem, it's conceptually far less burdensome on users if they only have to type the familiar command "ssh hostname" to get their session going, instead of having to type "systemd-inhibit ssh hostname" every time that they want to start a remote session. It creates quite a burden to have to teach everyone that "ssh hostname" no longer works and that they have to type "systemd-inhibit ssh hostname" every time they want to start a remote session. It's also unduly burdensome to have to add that "systemd-inhibit" nonsense in front of every console command that you want to execute without interruption when you spend most of your day at a console.

Is there a way for administrators to automate systemd-inhibit so that it works automatically based upon the context of the tasks that the user is performing, rather than only looking at the keyboard and mouse activity? My previous design did exactly this, and following the upgrade I'm now seeing a lot of user processes being stepped on, now that the system has suddenly become agnostic of what is going on in the user space.

2. Is there a way to automate the systemd-inhibit system so that it acts intelligently when it comes to not shutting the system down? The present implementation seems to only pay attention to KB and mouse activity, which is a very bad design. If my computer is performing a mathematically intensive task which may take several hours to complete, I don't want the system going to sleep while the CPU utilization is maxed at 100% just because systemd only pays attention to mouse movements and keystrokes. In this context, it appears obvious that systemd-inhibit was written by people who view computers as nothing more than word processing and spreadsheet hosts that are expected to receive continuous kb/mouse input. It would appear that these people designed the sleep system in a context that pays attention only to the keyboard and to the mouse, and turns a blind eye to what processes are running and what the CPU is actually doing. All things considered, I think it's a giant step backwards.

robertdaleweir
20th September 2016, 05:23 AM
Thanks again for your help. For those scripts that are run in cron tasks, it would seem simple enough to prefix them with the instructions that you've recommended. That's not overly burdensome, as the cron editing only needs to happen once, and the tasks can be repeated on schedule without additional user intervention.

I have another question and the burden that these new "enhancements" place on end-users.

1. Suppose that a user wants to ssh into a remote host, and the sysadmin wants to configure the system so that suspend/sleep states on the system don't terminate a user's ssh session. Is there a way for the administrator to automate this, so that the system is smart enough not to squash user sessions? Or does the burden fall upon the user to wrap every console command with systemd-inhibit every time that he executes an ssh session? In the instant cases, I'm seeing the system go to sleep during the middle of file transfers, just because systemd is only paying attention to the keyboard and mouse, and completely ignores network traffic and cpu utilization.

In order to prevent this problem, it's conceptually far less burdensome on users if they only have to type the familiar command "ssh hostname" to get their session going, instead of having to type "systemd-inhibit ssh hostname" every time that they want to start a remote session. It creates quite a burden to have to teach everyone that "ssh hostname" no longer works and that they have to type "systemd-inhibit ssh hostname" every time they want to start a remote session. It's also unduly burdensome to have to add that "systemd-inhibit" nonsense in front of every console command that you want to execute without interruption when you spend most of your day at a console.

Is there a way for administrators to automate systemd-inhibit so that it works automatically based upon the context of the tasks that the user is performing, rather than only looking at the keyboard and mouse activity? My previous design did exactly this, and following the upgrade I'm now seeing a lot of user processes being stepped on, now that the system has suddenly become agnostic of what is going on in the user space.

2. Is there a way to automate the systemd-inhibit system so that it acts intelligently when it comes to not shutting the system down? The present implementation seems to only pay attention to KB and mouse activity, which is a very bad design. If my computer is performing a mathematically intensive task which may take several hours to complete, I don't want the system going to sleep while the CPU utilization is maxed at 100% just because systemd only pays attention to mouse movements and keystrokes. In this context, it appears obvious that systemd-inhibit was written by people who view computers as nothing more than word processing and spreadsheet hosts that are expected to receive continuous kb/mouse input. It would appear that these people designed the sleep system in a context that pays attention only to the keyboard and to the mouse, and turns a blind eye to what processes are running and what the CPU is actually doing. All things considered, I think it's a giant step backwards.

Hi bob p
I do not have any idea about the number 2 of your questions but you could populate your user 'bashrc' with an 'alias' which could be something like
alias ssh='systemd-inhibit ssh' You could of course use another name but using this would address your problem. It would also work at your console.
Cheers...