Inhibit Sleep when running certain kinds of tasks

Brainstorm
1

(Arguably terminals should take suspend inhibitors to turn off the auto suspend when a command is executing. But they don’t.)

@mcantazaro power: Add increase power consuption description for automatic suspend (!3082) · Merge requests · GNOME / Settings · GitLab

  • We want to inhibit when running stuff like pacman, wget, cp or mv
  • We don’t want to inhibit when running stuff like htop, less, watch

Should we be looking into implementing this in konsole or is it better to implement this in the shell (bash, zsh etc.) or the programs themselves?

1 Like
2

Hi - I think the catch is that for Konsole to handle that itself, it would theoretically have to inspect what’s happening inside the terminal, and infer that status. Ideally, I think programs that are harmed by sleep occurring should set that inhibition themselves.

If you have terminal applications that aren’t set up to do that, you can still inhibit sleep directly using systemd-inhibit .

2 Likes
3

Yes, ultimately only the programs themselves know what they are doing.

The terminal could “make a guess” and inhibit sleep if it has any program running and is the focused window (e.g. the user might actively be watching top)

The terminal or shell could potentially have some sort of whitelist for programs that are usually blocking on I/O or some other long running task but such a list could grow quickly.

Some programs have different modes of operation, some of which would benefit from that while others would not.
For example a file manager like Midnight Commander: idle unless some operations is triggered by the user.

The kernel, or something intercepting system API calls, might theoretically be able to detect common patterns of IO activity that last longer, e.g. sequence of reads on a large file or holding a connected socket.

However, without knowing what the actual task is, this is potentially also brittle.
If the reads stop, for example, does that mean the program is done with IO or just processing what it has read so far?

The most feasible workaround is probably to have shell aliases which use systemd-inhibit and the actual command, leaving it up to the user to tell the system “I want this done without interruption”.

2 Likes
4

Yes, shell aliases using system-inhibit seems to be the way to go.

Probably out of KDE’s scope and more for the distros themselves, if not the user.