Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #275382 > unrolled thread

Automatic suspend-to-ram solution for Workstations

Back to article view | Back to linux.debian.user

Contents

  Automatic suspend-to-ram solution for Workstations Felix Natter <fnatter@gmx.net> - 2024-12-07 20:30 +0100
    Re: Automatic suspend-to-ram solution for Workstations Will Mengarini <seldon@eskimo.com> - 2024-12-07 21:20 +0100
    Re: Automatic suspend-to-ram solution for Workstations Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-09 14:00 +0100
      Re: Automatic suspend-to-ram solution for Workstations Max Nikulin <manikulin@gmail.com> - 2024-12-10 04:20 +0100
    Re: Automatic suspend-to-ram solution for Workstations Jan Claeys <lists@janc.be> - 2024-12-13 17:50 +0100
      Re: Automatic suspend-to-ram solution for Workstations Henrik Ahlgren <pablo@seestieto.com> - 2024-12-13 18:30 +0100

#275382 — Automatic suspend-to-ram solution for Workstations

Dear Debian users,

I am looking for an automatic suspend-to-ram (I know "sudo systemctl
suspend" ;-)) solution for workstations: I would like the system to
suspend if and only if:

- there is no gui interaction from any user (especially with VNC
  sessions) AND
  
- there is no significant load during the last hour (in order to account
  for backup jobs)

I am using the mate desktop, if that makes any difference.
Of course the desktop must be locked before suspension.

Maybe systemd can support this in coop with the DE?

I think Windows can do it, but Windows does not allow multiple users
logged in at the same time, so it is an easier task.

Am I asking too much? 

Many Thanks in Advance!
Felix
-- 
Felix Natter

[toc] | [next] | [standalone]

#275384

* Felix Natter <fnatter@gmx.net> [24-12/07=Sa 20:27 +0100]:
> [...] no significant load during the last hour [...]

The system doesn't keep track of load for a
full hour, but it does for fifteen minutes.
  uptime|awk '{print $NF}'
is load average for the past 15 minutes.

> [...] no gui interaction [...] (especially with VNC [...]) [...]

That's a lot harder.  Theoretically `w` shows idle time, but
I'm not sure you can trust it with layers of GUI interaction.

Full original post:
> I am looking for an automatic suspend-to-ram (I know "sudo systemctl
> suspend" ;-)) solution for workstations: I would like the system to
> suspend if and only if:
>
> - there is no gui interaction from any user (especially with VNC
>   sessions) AND
>
> - there is no significant load during the last hour (in order to account
>   for backup jobs)
>
> I am using the mate desktop, if that makes any difference.
> Of course the desktop must be locked before suspension.
>
> Maybe systemd can support this in coop with the DE?
>
> I think Windows can do it, but Windows does not allow multiple users
> logged in at the same time, so it is an easier task.
>
> Am I asking too much?

[toc] | [prev] | [next] | [standalone]

#275418

Felix Natter <fnatter@gmx.net> writes:

> Dear Debian users,
>
> I am looking for an automatic suspend-to-ram (I know "sudo systemctl
> suspend" ;-)) solution for workstations: I would like the system to
> suspend if and only if:
>
> - there is no gui interaction from any user (especially with VNC
>   sessions) AND

I think every desktop environment has this. Even X has this. 'This'
being a timer since last mouse or keyboard event and the ability to
trigger a command on the timer. I looked recently but didn't really find
a way to do the Windows like thing, turn off screen->suspend->hibernate
with configurable intervals. Desktop environments do have that and KDE
does it fine on my Linux laptop but with just X11 and a WM it's a
different story.

> - there is no significant load during the last hour (in order to account
>   for backup jobs)

This is the hard part, define load. Especially now that the logged in
user might have a browser running with a few dozen or a few hundred
tabs, all full of Javascript code, some of which probably wants to run
sometimes or all the time.

I think Windows (and maybe Macs?) have gone the other way, they have
process settable bits to indicate system is in use. Handy for video
players, for example, but backup jobs too. I don't know if Linux has
anything like that. Well, you can disable the X screensaver which
probably works for movies but that doesn't matter a whole lot to a batch
backup job.

> I think Windows can do it, but Windows does not allow multiple users
> logged in at the same time, so it is an easier task.

At least today's Windows (10 and 11) do allow multiple users logged in
and I think XP over two decades ago had "switch user" in there, allowing
multiple simultaneous logins.

[toc] | [prev] | [next] | [standalone]

#275448

On 09/12/2024 19:53, Anssi Saari wrote:
> I think every desktop environment has this. Even X has this. 'This'
> being a timer since last mouse or keyboard event and the ability to
> trigger a command on the timer. I looked recently but didn't really find
> a way to do the Windows like thing, turn off screen->suspend->hibernate
> with configurable intervals. Desktop environments do have that and KDE
> does it fine on my Linux laptop but with just X11 and a WM it's a
> different story.

(I would leave aside VNC sessions at least for a while.)

Screensavers that are able to put monitors in standby state (sometimes 
without stopping to eat CPU though) have been existing for decades. I do 
not expect that any of them may suspend the machine out of the box. 
Perhaps some of them might allow to configure a custom user command.

Nowadays GUI applications communicate through D-Bus. You may try e.g. 
light-locker that notifies systemd-logind about user inactivity. My 
impression is that systemd allows suspending after some interval of time.

> Handy for video
> players, for example, but backup jobs too. I don't know if Linux has
> anything like that. Well, you can disable the X screensaver which
> probably works for movies but that doesn't matter a whole lot to a batch
> backup job.

Applications may inhibit screensaver and screen locker (e.g. 
"light-locker-command --inhibit"). For system-critical tasks there is 
systemd-inhibit(1) and I would consider it for backups instead of 
load-based heuristics.

[toc] | [prev] | [next] | [standalone]

#275651

On Sat, 2024-12-07 at 20:27 +0100, Felix Natter wrote:
> - there is no significant load during the last hour (in order to
> account for backup jobs)

Assuming this backup is started by an automated system under control of
the sysadmins, and not by the users themselves, it's probably easiest
to use some sort of "lock" that is set by the backup process itself (or
that you wrap around it).

Otherwise there probably isn't any good, error-free way to determine
what "load" should inhibit sleep or not...


-- 
Jan Claeys

(please don't CC me when replying to the list)

[toc] | [prev] | [next] | [standalone]

#275655

On Fri, 2024-12-13 at 17:44 +0100, Jan Claeys wrote:
> Assuming this backup is started by an automated system under control of
> the sysadmins, and not by the users themselves, it's probably easiest
> to use some sort of "lock" that is set by the backup process itself (or
> that you wrap around it).

Set up a systemd timer job for automatic backups, using WakeSystem=true
to make RTC resume the system if it is suspended during when the backup
is scheduled to run. Then wrap the backup command with "systemd-inhibit
--what=idle" to keep the system awake during the backup process.

The only problem I've seen with this setup is that even with 

	After=network-online.target nss-lookup.target
	Wants=network-online.target nss-lookup.target

the network isn't always fully online when the job starts. Does anyone
know a reliable way of ensuring that with systemd configuration
(without workarounds like sleep-before-starting)? Any why doesn't
network-online.target work when resuming from sleep?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web