0

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
8
  • 7
    If you server is still up&running and healthy after 7 days uptime, why on earth do you want to reboot it daily? Commented Nov 17, 2012 at 10:25
  • 3
    @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. Commented Nov 17, 2012 at 10:35
  • 8
    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. Commented Nov 17, 2012 at 11:54
  • 1
    Removed the whole "don't do that" discussion, since it got a bit long without actually solving anything Commented Nov 19, 2012 at 4:35
  • 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). Commented Nov 19, 2012 at 14:04

4 Answers 4

Reset to default
8

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
2
  • 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. Commented Nov 18, 2012 at 5:53
  • "If the reboot command is not on the executing shell's PATH, cron might simply not find it" that nailed it in my issue. Changing it to /sbin/reboot solves it. Thanks. Commented Apr 25, 2022 at 20:02
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
3
  • @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. Commented Dec 2, 2013 at 9:56
  • What does the2>&1 stand for? Commented Oct 23, 2016 at 23:31
  • 1
    @IgorGanapolsky: >/dev/null discards standard output. 2>&1 directs stderr to the same place, so all output is discarded. Commented Oct 24, 2016 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
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
1
  • 2
    The files in /etc/cron.d have the same format as /etc/crontab which has a username after the time spec. Commented Nov 17, 2012 at 21:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.