shutdown via cron? [solved]

[murray]

I've got my computer turning itself on at 10pm every night and running a bash script via cron. The script uses wget to run a PHP script on a web server that dumps some MySQL databases, zips up the dumps and emails them to me. After doing this I want the bash script to shut down my computer.

Here's the bash script:

Code: Select all

#!/bin/bash
# Run the backup script to backup all client MySQL databases on iServe

echo "Starting database backup"
outputFile="/home/murray/cron/clientdbs/$(date +%Y%m%d).txt"
logFile="/home/murray/cron/clientdbs/log.txt"
wget --append-output=$logFile --output-document=$outputFile --user=backup --password=xxxxxx http://xxxxxx.com/backup.php?verbose=1
exitCode=$?
if [ $exitCode -ne 0 ]; then
  echo "wget returned error code $exitCode"
else
  echo "Finished database backup"
fi

/sbin/shutdown -h --no-wall +3

Initially I had the bash script running from the system crontab and it was working ok but then I decided it would be better to run it from my personal crontab instead. After moving it over to my personal crontab everything worked except for the shutdown at the end.

cron emails me all the output from the bash script, this is what I receive:

Code: Select all

Starting database backup
Finished database backup
Failed to set wall message, ignoring: Interactive authentication required.
Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Interactive authentication required.

It looks like the shutdown command requires authentication, even though I can run it ok manually from a CLI without having to sudo it. I'm also unsure why it's complaining about setting a wall message when I've used the --no-wall option to specify that I don't want one.

I did a bit of Googling and found I could edit the sudoers files to specify that my user didn't require authentication for the shutdown command, so I did this by adding the following line: murray ALL=(ALL:ALL) NOPASSWD: /sbin/shutdown

If I do a sudo -l this is what I receive:

Code: Select all

Matching Defaults entries for murray on mercury:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
pwfeedback

User murray may run the following commands on mercury:
(ALL : ALL) ALL
(root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
(ALL : ALL) NOPASSWD: /sbin/shutdown

So it looks like sudoers is now set up to say that I don't need to enter a password when using the shutdown command. Unfortunately this didn't help, I still receive the same error message.

Have I done something wrong? How can I run shutdown via my personal crontab? Or is there a better way to do what I'm trying to do?

[all41]

Have you tried using systemctl poweroff ?

[murray]

Have you tried using systemctl poweroff ?

No, I'll give it a try tonight and see how it goes. Thanks for the suggestion!

[rene]

It is polkit that is denying access. It discriminates between "active sessions on a local console" and other types such as an ssh login or, indeed, cron. In the output of

Code: Select all

pkaction -v --action-id org.freedesktop.login1.power-off

you will by default see the authentication result returned for "active" to be "yes" but for "any" and "inactive" to still need authentication as admin.

The way to configure this is to supply an override in /etc/polkit-1/localauthority/. Since this as mentioned applies to e.g. ssh logins as well most people will want to do same as in the below example, and which says to just allow any login1 action, but if you insist you can limit the actions with help of the security section of https://www.freedesktop.org/wiki/Softwa ... md/logind/. I.e., you could limit implicit authentication to org.freedesktop.login1.power-off and friends if so desired

But to open up all logind actions to (mind you) administrator users, also when logged in via ssh and cron and the like, you'd create a file e.g. /etc/polkit-1/localauthority/50-local.d/org.freedesktop.login1.pkla containing

Code: Select all

[org.freedesktop.login1]
Identity=unix-user:0;unix-group:sudo;unix-group:admin
Action=org.freedesktop.login1.*
ResultAny=yes

Both the name of the file except for the .pkla suffix and the bit between [ .. ] is free-form. The "Identity" bit limits the privilege to root and members of group "sudo" and/or "admin", i.e., the same as what Ubuntu/Mint systems consider an Administrator user to be in the first place.

You won't need to reboot to have the new policy active once you dump that file in: polkit monitors those directories. See man polkit and man pklocalauthority for further detail.

[murray]

Have you tried using systemctl poweroff ?

No, I'll give it a try tonight and see how it goes. Thanks for the suggestion!

Well that suggestion didn't work last night.

Time to try rene's suggestion, which I have high hopes for. I'll report back tomorrow.

[rene]

If you are needing actual days to test this as a direct consequence of this being done "at 10pm every night", note that you can just schedule a test for the next minute with e.g.

Code: Select all

(crontab -l 2>/dev/null; echo "$(($(date +%M)+1)) * * * * /sbin/shutdown -h now") | crontab

Use crontab -e to delete the line again once satisfied lest it'd fire again next hour.

[EDIT] Hope I was fast enough editing that; the first version did not append but replaced your crontab...

[murray]

If you are needing actual days to test this as a direct consequence of this being done "at 10pm every night", note that you can just schedule a test for the next minute with e.g.

Code: Select all

(crontab -l 2>/dev/null; echo "$(($(date +%M)+1)) * * * * /sbin/shutdown -h now") | crontab

Use crontab -e to delete the line again once satisfied lest it'd fire again next hour.

Nice, I can see you're a whizz on the command line!

[EDIT] Hope I was fast enough editing that; the first version did not append but replaced your crontab...

Phew, lucky I was doing the supermarket shopping while you were replying so I didn't trash my crontab

[FreedomTruth]

Or is there a better way to do what I'm trying to do?

"Better" is always subjective. I'm curious why you don't just have your webserver run the dump, zip, and email in a cron job? It just seems like this is a complicated way of doing it.

[murray]

I'm curious why you don't just have your webserver run the dump, zip, and email in a cron job? It just seems like this is a complicated way of doing it.

Because this web hosting company doesn't offer cron jobs. The only reason I use them is because I'm getting the hosting for free. They do their own backups but I want to play it safe, plus I thought this would be an interesting exercise.

[murray]

It's all working now.

Many thanks @rene, your suggestion was spot on.