Cron shutdown fails to execute

General Help
1

Hi-

Using Zorin on a couple public access computers, and am having trouble getting a cron job to run, purpose is to shut the computer down after hours. Bios can turn it back on.

Session is run under a guest user without admin privileges, and the usual solutions such as

00 10 * * * sudo shutdown -h now

don't seem to work.

Guest is not member of sudoers group, wonder if making them a member is a good idea?

I've of course checked all the Ubuntu forums for answers, nothing seems to work.
The rest of the cron job runs fine. (I use bleachbit preset to delete some files and folders, and a shell script to restore my home folders)

Any help would be greatly appreciated.

2

Anacron, perhaps?

-- or --

00 10 * * * /sbin/poweroff -f

More info on poweroff:
man poweroff

-- or --

00 10 * * * systemctl start poweroff.target --job-mode=replace-irreversibly --no-block

-- or --

00 10 * * * systemctl start poweroff.target --force

-- or (if you want it to shut down no matter what, without closing programs, etc. (NOT recommended)) --

00 10 * * * systemctl start poweroff.target --force --force

More info on systemctl:
man systemctl

There's an easier way... a kernel parameter which makes the OS 'stateless'... I was just reading about it today... let me see if I can find if again.

[EDIT]
Mheh... I can't find it. It was a Grub parameter, it allowed the OS to save files (so you could update it), but user changes were saved to volatile storage (RAM) and were wiped when the machine rebooted.

3

From the command line:

$ /usr/sbin/poweroff -f
Need to be root.

``Nothing happens when a cron job is run 

I suspect this poweroff command needs to be run as root.
4

Put sudo -i in front of it and see if it works.

5

That powers it off, requesting a sudo user password to initiate.

6

sudo -iS <<< "password" command

So it should be:
sudo -iS <<< "your password" shutdown -h now

I'm kind of flying blind here, since I've got my sudo password timeout set to a full day.

1 Like
7

Thanks, that worked as a shell script called from a crontab.

Did not work directly from the crontab.

I'll add it on to the production machine tomorrow and double check, hopefully good to go.

Testing is a bit awkward, and to complicate matters the target device has a Spanish keyboard, which has also been challenging.

Appreciate the help!

1 Like
8

Whew! Wasn't sure that was going to work. If you get a chance, peruse the Grub man pages, I know I saw a parameter in there that lets the OS save files, and the users can make changes but they're wiped when the machine reboots... that'd make your task a lot easier. I think that's what that Intel Clear Linux does.

1 Like
9

Interesting concept. If what I have with the addition of the shutdown works, I'm going to have to go with it. I'm running short of days left here, and need to get this stuff buttoned up.

Thanks again, I will check out the grub man pages and see what that's about.

1 Like
10

Well, didn't work on the actual machine. Seems like on my private machine, I'm a member of the sudo group. Not so on the public computer.

11

Can you run the script under a certain user, then set up sudo to not ask for a password from that user?

00 10 * * * gitm command

So something like:
00 10 * * * gitm /usr/sbin/poweroff -f
... or whatever your path and command is.

If that doesn't work, try:
00 10 * * * gitm sudo -i /usr/sbin/poweroff -f

sudo visudo
or
sudoedit /etc/sudoers

Enter the following:

# Allow {username} to execute any command
gitm		ALL=(ALL) NOPASSWD:ALL

Where "gitm" is a user (Ghost In The Machine) used only for auto shutdown and other auto-admin scripts.

12

Not sure, I'd have to research it and try it out.

I find it hard to believe that while an user can shutdown a system at the click of a button, it's this hard to script the action without running into these permissions issues.

I have added the user to the admin group, and using the user pwd in the script allows the command to work. Of course, this isn't the best from a security point of view. Considering the users, probably not too risky.

Thanks!

13

I ran across this:

gnome-session-quit [--logout|--power-off|--reboot] [--force] [--no-prompt]

Tried it on a Fedora VM with a new non-privleged user.
This combination seemed to work
gnome-session-quit --power-off --force

Will try it on Zorin public pc's tommorow after revoking users admin privleges.

14

Ran fine from the terminal, running from crontab failed. Oh well!

15

From https://unix.stackexchange.com/questions/208205/how-to-schedule-shutdown-every-day

And yet another way:

The shutdown command has already an embedded scheduler so you don't need a cron job for it to run at the specified time. In Linux as everywhere else, it's better to stick to the KISS principle (Keep It Short and Simple).

shutdown -h 22:00 will work fine, no need to run it in the background. Add the command at the end of /etc/rc.local (or /etc/rc.d/rc.local depending on your system) for execution in the last startup script.

The advantage of not using cron is that in this way the shutdown remains scheduled during the day, and you can cancel it at any time by typing

shutdown -c

Anyone know where the rc.local file or it's equivalent resides in Zorin?

16

Are you talking about where you put user executable scripts?
/usr/local/bin

I'd just create a script that calls shutdown -h 22:00, make it executable, drop it into /usr/local/bin, then call it from Zorin menu > System Tools > Startup Applications.

As soon as the machine boots, it's got the command to shutdown at the specified time.

Or you can set it to run as a service, so the user never even sees any command prompt. Here's a quick how-to, used to remap the hard drive light to a keyboard light, but you can do the same for the shutdown command:

So let's say you want to name your script "autosd".

Create a text file with your shutdown script in it. Save it to /etc/init.d/autosd.

Set the file as executable:
sudo chmod +x /etc/init.d/autosd

Create a sym-link in the proper run level directory:
sudo ln -s /etc/init.d/autosd /etc/rc5.d/S01autosd

You want to use /etc/rc5.d, the 5th run-level, as that's the desktop... so as soon as the machine boots far enough to get to the graphical desktop, it'll have a command to shut down at the specified time.

You might want to put a wall message so anyone still using the machines don't freak out when it shuts down on them.

More info:
man shutdown
man wall

17

That worked on my machine, will check on the public pc's tomorrow.
Thanks for the guidance, I'll keep my fingers crossed!

1 Like
18

Just keep in mind that might pop up a terminal window... if you don't want that, go with the second option I wrote of above... creating a service.

19

On my test run, it didn't, but I'm in the sudo group
On the public machines, I'll pull the guest out of that group and see what happens.
A terminal window is ok, as long as no input is needed.
The action will run afterhours, when nobody is at the computers.
The computers start up again in the am via the pc bios.

I read up on the why this poweroff issue is this way, goes way back to multi-user computers.

Taking a lot of my energy to save some energy!

20

Just found this... it might help you or a future admin who's attempting to secure a system:

gsettings set org.gnome.desktop.lockdown mount-removable-storage-devices-as-read-only false
gsettings set org.gnome.desktop.lockdown disable-command-line false
gsettings set org.gnome.desktop.lockdown disable-log-out false
gsettings set org.gnome.desktop.lockdown disable-printing false
gsettings set org.gnome.desktop.lockdown disable-lock-screen false
gsettings set org.gnome.desktop.lockdown disable-print-setup false
gsettings set org.gnome.desktop.lockdown disable-user-switching false
gsettings set org.gnome.desktop.lockdown disable-application-handlers false
gsettings set org.gnome.desktop.lockdown disable-save-to-disk false
gsettings set org.gnome.desktop.lockdown user-administration-disabled false