I would like to schedule a restart of my Ubuntu every 30 minutes. Is there any command or a graphical way to do it?
4 Answers
The best way to do this will depend on why you want Ubuntu to restart every half hour.
So I recommend editing your question to explain why you wish to do this.
Rebooting every 30 minutes, and warning users before each reboot:
Assuming people might be using the machine, either locally or remotely, it's best to avoid restarting Ubuntu from under them without any warning. Therefore, rather than scheduling the reboot
command, I recommend scheduling the shutdown
command so it warns the user.
To schedule a shutdown every half hour with a warning 5 minutes before, add this to /etc/crontab
:
#minute hour mday month wday user command
*/30 * * * * root shutdown -r +5
You don't actually have to add the fist line, which is a comment. I've included it for clarity--something like it is there already.
- This will schedule the system to go down for reboot (
-r
) five minutes after (+5
) the command runs. It runs every at every half hour mark (*/30
). Seeman cron
andman 5 crontab
. - Change
+5
to something else to change how long users have after being warned of reboots. 0,30
under minute will also work, if you prefer that. (Similarly, if it were every 20 minutes, you could write*/20
or0,20,40
.)- Make sure
/sbin
is in thePATH
variable specified near the top of/etc/crontab
. Otherwise,shutdown
(undercommand
) will have to be invoked as/sbin/shutdown
.
The command will always run on the half-hour mark, if the machine is up and running at that time. This will cause the shutdowns to be announced every half hour and performed at 5 minutes and 35 minutes past the hour.
- One benefit here is that an administrator can cancel the just-announced shutdown with
sudo shutdown -c
. - If the computer is down during the specific times when the scheduled command is to be run, it will not run. If that's not adequate to your needs, you'll have to schedule your reboots differently. (This is not specific to the use of
shutdown
but would apply equally if you were schedulingreboot
.) In that case, please edit your question to explain your specific needs. (I'd recommendanacron
for this, but your time intervals are far too short.)
Making it easier for administrators to prevent automatic reboots from happening at all:
You might want to set this up so that it's easy for an administrator to suspend all automatically scheduled reboots:
#minute hour mday month wday user command
*/30 * * * * root [ -e /etc/noautoreboot ] || shutdown -r +5
This schedules reboots the same way--every half hour, with five minutes warning--except that it will not schedule a reboot if a file called noautoreboot
exists in /etc
.
This control file can be created by an administrator with:
sudo touch /etc/noautoreboot
It can be deleted with:
sudo rm /etc/noautoreboot
Note that it's whether or not the file exists, not what it contains, that matters.
If the reboot is scheduled and users are warned, then the file is created, the (immediately upcoming) reboot will still occur.
How does this work? It uses a short-circuit-evaluated or operator (
||
) as shorthand for:If
/etc/noautoreboot
doesn't exist, runshutdown -r +5
.This answer explains how short-circuit and and or operators can perform
if
-then
logic. For a brief, intuitive and highly informal explanation, you can read the command this way:/etc/noautoreboot
exists! Or, runshutdown -r +5
.See
man [
to see how the test itself is performed.
I love doing this by telling the Session Manager we want to reboot. This can be done without root permissions, and we get a nice window that warns us that the system is going to be rebooted -even we can cancel the reboot if we like to.
The Graphical Way - Preferred Method
Install gnome-schedule
from the Ubuntu Software Center. If you don't want to install anything additional, do it the Terminal Way.
Open gnome-schedule
from the dash, create a new repeated task, and set these options:
- Description: Whatever you want
- Command:
dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.Reboot
- Choose X Application just below the command.
- Time and Date, Advanced:
- Minute: 0,30
Leave the other options at their default values. Click on Add.
The Terminal Way - No Need for Additional Software
Run from the terminal:
crontab -e
Add this line:
0,30 * * * * DISPLAY=:0 dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.Reboot
Save & exit. Assuming you are using nano
(the default one), press Ctrl+o and Ctrl+x.
Please notice this won't work if your DISPLAY is actually different from :0
, and that's the reason this method is not preferred. But, honestly, if you are rebooting your computer every 30 minutes, your DISPLAY will most probably always be :0
.
Not using Gnome or Unity?
Both methods explained above depends on some gnome components, found both on Gnome sessions and on Unity. If you want to do this on another environments (such as Kubuntu's KDE, Kubuntu's LXDE...) you better replace the command with this one instead:
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart
This won't ask for confirmation, and will restart inmediatly, but will work on all environments, assuming you have not manually uninstalled ConsoleKit, of course.
Run sudo crontab -e
from the command line and add this line to the file:
0,30 * * * * reboot
This tells the system to run the command reboot
every 30 minutes as root. For an overview of the time syntax, see here: http://linuxmoz.com/crontab-syntax-tutorial/
-
1
Use cron
to schedule a job every 30 minutes. Point that job at a shell script that simply has
reboot
in it.
Since cron
runs as root, you shouldn't need to do anything special in terms of permissions.
Update
Yes I do, in fact I never on any of my systems allow user based crontabs (There are better ways of allowing users to do user level scheduled tasks) cron was designed from the very beginning purely for system automation and not for users to schedule ordinary tasks. Things such as log rotations (which still happens today)
Reboot MUST be run as root to work correctly, the alternative is to set it's sticky bit, so that when run as a regular user it actually executes as root and works as expected, but in doing that your then opening your server up to allowing regular users to reboot it at will.
You could even possibly automate a call to SUDO, but I need to dig into that one, not sure if you can automate the need for a password with SUDO (I don't use it often, i prefer to just drop straight to a root shell using SU)
If you set it up in system wide crontab then everything is run as root, so my statement is accurate (I just neglected to mention that the system wide one should be used)
As for your question "Why Wrap it in a script?" well, why not? If the OP puts it in a shell script, then at some point in the future needs to add to it, he simply adds to the script, instead of having to open crontab locate the job, remove it, replace it with a shell script, then write a script with the old + new in.
Over 20 years as a Sys Admin / Developer working with systems as far back as Ultrix / Solaris and even VAX has taught me one major point.
If you can make it easier at the beginning, then it remains easy for it's life time.
I really don't get this "Minimalistic" attitude that a lot of modern day sys admins have, where doing as little as possible is the key to success. Most servers these days are easily 20 times+ more powerful than anything I ever started out on, and this kind of scenario (Wrapping in shell scripts) was recommended practice then, so there's really no argument for not doing it now.
Unless you really want to go hardcore Unix/Linux, in which case tag it all onto the cron entry, and pipe everything together the way it ought to be done :-)
However, I do digress, and also understand that many guys these days a thrown in at the deep end and told to make things work, as such they lack the time (and usually the inclination) to sit down and learn about new techniques (or old in this case) or even want to play with this stuff outside of work.
I personally, have a single server among the ones I run that's dedicated purely for me to play around on, so I can test things like this... which is better A or B, so it's not without reason that I advise on any of this.
-
-
-
2This is now no longer an answer at all! (Also, you're confusing the sticky bit and the setuid bit.) Jan 16, 2013 at 13:52
-
Yes it is an answer, I typed it, added it as an answer therefore it's an answer!!!– shawtyJan 16, 2013 at 14:26