I'd like to inhibit suspend while backups run on my laptop. I'm scheduling those backups with a systemd timer[1] and service[2]. I've read that the default polkit policy only permits inhibiting suspend from within a login session, so I've also tried to add rules to allow the root user to inhibit suspend[3]. However, with all of those in place, I still get errors that I think indicate that the "systemd-inhibit" command is failing[4].
I'm running this on Fedora 33. Has anyone successfully used systemd-inhibit from a systemd unit?
1: # cat /usr/lib/systemd/system/run-borg.timer
[Unit] Description=Periodic borg backup
[Timer] OnCalendar=08..20/2:00 Persistent=true
[Install] WantedBy=timers.target
2: # cat /usr/lib/systemd/system/run-borg.service [Unit] Description=Run borg backup RequiresMountsFor=/var/log ConditionACPower=true
[Service] Type=oneshot ExecStart=/usr/bin/systemd-inhibit --who=borg-backup '--why=Backup in progress' --mode=block /root/run-borg
3: # cat /etc/polkit-1/rules.d/root-inhibit-suspend.rules polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.login1.inhibit-block-shutdown" && subject.isInGroup("root")) { return polkit.Result.YES; } });
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.login1.inhibit-block-sleep" && subject.isInGroup("root")) { return polkit.Result.YES; } });
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.login1.inhibit-block-idle" && subject.isInGroup("root")) { return polkit.Result.YES; } });
4: Mar 21 18:00:41 vagabond systemd[1]: Starting Run borg backup... Mar 21 18:00:41 vagabond systemd-inhibit[19767]: read: Connection reset by peer Mar 21 18:00:41 vagabond systemd-inhibit[19761]: /root/run-borg failed with exit status 1. Mar 21 18:00:41 vagabond systemd[1]: run-borg.service: Main process exited, code=exited, status=1/FAILURE Mar 21 18:00:41 vagabond systemd[1]: run-borg.service: Failed with result 'exit-code'. Mar 21 18:00:41 vagabond systemd[1]: Failed to start Run borg backup.
On 22/03/2021 11:07, Gordon Messmer wrote:
I'd like to inhibit suspend while backups run on my laptop. I'm scheduling those backups with a systemd timer[1] and service[2]. I've read that the default polkit policy only permits inhibiting suspend from within a login session, so I've also tried to add rules to allow the root user to inhibit suspend[3]. However, with all of those in place, I still get errors that I think indicate that the "systemd-inhibit" command is failing[4].
I'm running this on Fedora 33. Has anyone successfully used systemd-inhibit from a systemd unit?
I have not used, or even tried to use, systemd-inhibit.
But, when testing things I like to use examples which use simple system commands. To verify that things work as I think they should in various ways before trying my commands/scripts.
FWIW, I ssh'ed into a system and ran....
sudo /usr/bin/systemd-inhibit sleep 30
In another terminal, systemd-inhibit --list showed
sleep 30 0 root 2634 systemd-inhibit shutdown:sleep:idle
I then created a crontab for root of
00,10,20,30,40,50 * * * * /usr/bin/systemd-inhibit sleep 60
and at the appropriate minute in time systemd-inhibit --list showed
sleep 60 0 root 2681 systemd-inhibit shutdown:sleep:idle
The crontab, in particular, isn't a login session. Note: --mode=block is the default according to the man page.
So, does your backup process work when called from crontab entry?
On 22/03/2021 14:08, Ed Greshko wrote:
But, when testing things I like to use examples which use simple system commands. To verify that things work as I think they should in various ways before trying my commands/scripts.
Along those lines....
[egreshko@f33k ~]$ cat /etc/systemd/system/mycron.timer [Unit] Description=Test Cron
[Timer] OnCalendar=*:00/10 Persistent=True
[Install] WantedBy=timers.target
[egreshko@f33k ~]$ cat /etc/systemd/system/mycron.service [Unit] Description=Testing myCron
[Service] Type=oneshot #ExecStart=/usr/bin/touch /var/tmp/auto/myCron ExecStart=/usr/bin/systemd-inhibit --who=ME --why=whynot /usr/bin/sleep 300
And when the time arrives
[root@f33k system]# date Mon Mar 22 07:20:05 PM CST 2021
[root@f33k system]# systemctl status mycron.timer ● mycron.timer - Test Cron Loaded: loaded (/etc/systemd/system/mycron.timer; enabled; vendor preset: di> Active: active (running) since Mon 2021-03-22 19:00:42 CST; 19min ago Trigger: n/a Triggers: ● mycron.service
Mar 22 19:00:42 f33k.greshko.com systemd[1]: Started Test Cron.
[root@f33k system]# ps -eaf | grep 300 root 1305 1 0 19:20 ? 00:00:00 /usr/bin/systemd-inhibit --who=ME --why=whynot /usr/bin/sleep 300 root 1308 1305 0 19:20 ? 00:00:00 /usr/bin/sleep 300
[root@f33k system]# systemd-inhibit --list WHO UID USER PID COMM WHAT WHY > ME 0 root 1305 systemd-inhibit shutdown:sleep:idle whynot > ModemManager 0 root 577 ModemManager sleep ModemManager nee> NetworkManager 0 root 703 NetworkManager sleep NetworkManager n> UPower 0 root 598 upowerd sleep Pause device pol>
4 inhibitors listed.
On 3/21/21 11:08 PM, Ed Greshko wrote:
So, does your backup process work when called from crontab entry?
Yes, it does, and that's part of what confused me. However -- and this is rather embarrassing -- the real problem was a missing environment variable in the script when the process was run as a systemd unit. I thought the log entry "systemd-inhibit[19767]: read: Connection reset by peer" was some sort of dbus problem reported by systemd-inhibit, but that text is really stderr from the script.
All sorted out and working as expected now.
On Tue, Mar 23, 2021 at 09:40:04PM -0700, Gordon Messmer wrote:
All sorted out and working as expected now.
This is pretty cool -- I'm thinking of something similar, as my new workstation system is a little too power-hungry to make me feel good about leaving on all the time. Do you have a blog post or repo with your complete solution?
On 3/24/21 11:17 AM, Matthew Miller wrote:
This is pretty cool -- I'm thinking of something similar, as my new workstation system is a little too power-hungry to make me feel good about leaving on all the time. Do you have a blog post or repo with your complete solution?
I keep this in a private Ansible repo, but I've pulled the relevant bits out and put them here:
On Wed, 2021-03-24 at 14:17 -0400, Matthew Miller wrote:
my new workstation system is a little too power-hungry to make me feel good about leaving on all the time.
It might be worth measuring what it actually uses.
A system may have a 500 watt power supply, but that's the amount its able to supply, not what it continually uses. The hardware that's installed will determine what is actually drawn from the supply, and if the system isn't actually doing much, the power draw will be a lot lower.
-
Ed Greshko -
Gordon Messmer -
Matthew Miller -
Tim