3

I'd like to suspend my laptop using at:

echo "systemctl suspend" | at now + 5 minutes

Suspension does not happen, instead I find a mail from at in /var/spool/mail/me:

Failed to set wall message, ignoring: Interactive authentication required.
Failed to suspend system via logind: Interactive authentication required.
Failed to start suspend.target: Interactive authentication required.
See system logs and 'systemctl status suspend.target' for details.

Alright, logind requires authentication when at runs systemctl suspend. This is interesting since when I run systemctl suspend directly, without at, no authentication is required and the machine goes into suspension.

I've made sure that the commands executed with at are run by the same non-root user as the commands run directly using echo "echo $(who) > who.txt" | at now.

Suspecting that authentication is required in at because it runs the commands via /bin/sh (which is an alias for bash), I executed systemctl suspend after starting /bin/sh: Suspending happens immediately without authentication, indicating that the nested shell is not the reason why suspending fails when done with at.

I get the same behavior and very similar mails when doing echo "reboot" | at now and echo "shutdown now" | at now.

My question is: How does logind figure out that it's at that tries to suspend, reboot, or shut down the machine and how can I tell logind that it should allow at to execute those commands without authentication?

I'm on Arch Linux 4.18.1 with at version 3.1.19.

jasonwryan
  • 73,126
Matthias Braun
  • 8,239

1 Answers1

1

Presumably the commands run by at are in a different environment, without access to your tty device and dbus settings and so on.

Systemd has its own version of the at command. You can use it to run your command in an environment that seems to be ok for further systemd commands. So use the equivalent command:

systemd-run --user --on-active=5min /bin/systemctl suspend

For perfect accuracy in the wait time of 5 minutes, you need to add option --timer-property=AccuracySec=1.

meuh
  • 51,383
  • Thanks @meuh, systemd-run works great. @jasonwryan added the polkit tag to the question; do you think that's part of the environment that's different in at? – Matthias Braun Aug 28 '18 at 17:29
  • Sorry, I don't know much about polkit. It's all very compilcated. The at command is very old, so might sit outside all this new stuff. It is probably the same as for cron. You'll see many questions on having trouble making commands work from cron. If there are any solutions they probably apply to at too. man systemd-logind.service mentions policykit and provides some links to explore. – meuh Aug 28 '18 at 17:39