-4

I have set this cronjob because I want my server to be rebooted everyday at 05:00

# file: /etc/cron.d/reboot
* 5 * * * root reboot &> /dev/null

I think it worked the first time as I was kicked out of the ssh connection. But now I came back some days later and found this:

$ uptime
07:12:13 up 7 days

Does this mean that it hasn't rebooted in 7 days? What is wrong?

|improve this question
  • 7
    If you server is still up&running and healthy after 7 days uptime, why on earth do you want to reboot it daily? – Mat Nov 17 '12 at 10:25
  • 1
    @Mat Because I don't want surprises. Sometimes it goes down, and then it takes hours to come back. The delay in coming back only happens when it's been up for too long. So I prefer to reboot everyday at 5 am when there aren't many visits (it's a web server). It comes back so fast that it manages to answer pending requests before they time out. I'm not a sysadmin, so there might be a better way obviously. But right now I need this. – ChocoDeveloper Nov 17 '12 at 10:35
  • 7
    Note that while this doesn't explain your issue, your crontab is wrong. It'll fire every minute between 5am and 6am. Change the first * to a 0. – Dennis Kaarsemaker Nov 17 '12 at 11:54
  • @DennisKaarsemaker Thanks, I will try that. – ChocoDeveloper Nov 17 '12 at 15:30
  • 2
    @ChocoDeveloper I'd guess that sometimes taking a while to come back is a fsck being forced after X days. Unfortunately, rebooting daily won't actually stop that. In fact, there is also a fsck after Y mounts, so it'll make it happen more. You can change this with tune2fs (if you're using ext2/3/4). – derobert Nov 19 '12 at 14:04
6

As the other commentators said, if uptime reports 7 days of uptime, the system hasn't rebooted in that while.

Besides @Dennis' correct comment, remove the pipe to /dev/null temporarily, then check root's mail and /var/log/syslog.

If the reboot command is not on the executing shell's PATH, cron might simply not find it.

Some systems don't have the reboot command, in which case you'd need to use shutdown -r now.

|improve this answer
  • Thanks. I don't have a MTA configured so I tried redirecting the output to a file. I had to use the absolute path to reboot, that worked fine. – ChocoDeveloper Nov 18 '12 at 5:53
3

The &> syntax for redirecting both stderr and stdout works in bash, but it likely doesn't work in /bin/sh, which is used to execute cron commands.

Try this:

0 5 * * * root reboot > /dev/null 2>&1

This also fixes the timing error pointed out by Dennis Kaarsemaker's comment.

(I'm not commenting on whether this is a good idea in the first place.)

|improve this answer
  • Now we are talking! I'm gonna try this, thanks – ChocoDeveloper Nov 18 '12 at 4:19
  • @Michael Kjörling: >& and &> both work in bash; only >& works in csh and tcsh. Since the question uses &>, and csh and tcsh aren't relevent, I've deleted the reference to them. – Keith Thompson Dec 2 '13 at 9:56
  • What does the2>&1 stand for? – IgorGanapolsky Oct 23 '16 at 23:31
  • 1
    @IgorGanapolsky: >/dev/null discards standard output. 2>&1 directs stderr to the same place, so all output is discarded. – Keith Thompson Oct 24 '16 at 0:32
1

I think the best answer I can give you is to get a sysadmin who can find out what's wrong with the box and why reboots take so long. All other possible solutions to your "problem" (such as checking $PATH, using the absolute path to reboot or using shutdown -r) are merely workarounds that will make your cronjob work but keep you blind as to what's actually wrong.

|improve this answer
0

Check the man page for the cron you have installed. It can do various things, depending on the implementation - like setting only specific variables (i.e. not PATH, which could cause reboot not to be found) before performing the required action.

Apart from the incorrect first asterix in time definition, I believe the "root" string is incorrect, and the file should look like:

# file: /etc/cron.d/reboot
0 5 * * * reboot &> /dev/null

otherwise it fails since it tries to call root with argument reboot. If you want to set root's crontab, you have to run the crontab (or whatever you use to set the jobs specification) command as root.

|improve this answer
  • 2
    The files in /etc/cron.d have the same format as /etc/crontab which has a username after the time spec. – user591 Nov 17 '12 at 21:46
  • @Iain thanks, I somehow didn't notice this. – peterph Nov 19 '12 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.