0

One of our DBAs created the following crontab entry to run a backup every 3 hours starting 6:30 AM to midnight every day:

30 6-24/3 * * * (path to backup script)

Cron took the entry but did not run the backup as expected. I am not a sysadmin or a Linux expert. My analysis is that the entry should have been (since hour never equals 24):

30 6-23/3 * * * (path to backup script)
  1. Which entry is correct? If the first entry is wrong, why did crontab allow the DBA to create the entry? It should have thrown an error.
  2. If I wanted to create an entry to run backup every 3 hours starting 6:30 AM to 11:30 PM, how would I create a crontab entry? There is no example which shows a time range which ends on half hour.

Edit: the system is Oracle Enterprise Linux 5.

The script only ran once before 2300. I will do some more testing and post back. I am still confused how cron accepted illegal value for hour (24).

This is weird. If I create an entry like:

30 6-24/3 * * * /bin/ls

I cannot save crontab. I get an error that hour is bad. If I create an entry like:

30 6-24/4 * * * /bin/ls

I can save the entry. It does not make sense. The hour is still bad and is accepted. Is this a bug or an expected behavior?

MadHatter: Please feel free to change the title of the post and file a bug. As I said, I am not a Linux expert, just someone that co-workers discuss technical issues with. I really like this site. The contributors are knowledgeable and willing to help.

Thanks, Arun

3
  • OS, and if Linux, distro? Version?
    – MadHatter
    Oct 2, 2014 at 19:53
  • In what way did it not work as expected ? Did it not run at all, too many times too few times ?
    – user9517
    Oct 3, 2014 at 12:47
  • 1
    This question is deeper than meets the eye. I can reproduce the behaviour described in the edit section on CentOS5, C6, and Fedora 20. I'm leaving the cron job running (under F20) to see when it does, or doesn't, trigger. Arun, I've changed the title to make it clearer what I think the interesting bit of the question is; if you disagree, you should of course feel free to change it as you see fit.
    – MadHatter
    Oct 3, 2014 at 14:08

2 Answers 2

1

This is pretty clearly a bug, and it seems to affect Red Hat systems of a number of flavours. I've confirmed the behaviour you describe on CentOS 5, C6, Fedora 19, and Fedora 20.

For crontab entries of the form

30 a-b/c * * *  /bin/ls

it seems that if there exists no positive integer n for which a+nc is in the range [24,b], the invalidity check for the final hour (b) is ineffective. That is, you can write gibberish as long as the OS doesn't actually have to do anything about it; if you specify a range and spacing such that it would actually trigger a job at an invalid hour (which includes 24) then crontab complains.

I've just persuaded my F20 system to accept the crontab entry

30 6-33/16 * * *  /bin/ls

which is insane by any standards. Similarly, 30 2-33/14 * * * /bin/ls and 30 1-33/16 * * * /bin/ls both give the (desirable) bad hour error, while 30 2-27/14 * * * /bin/ls is valid.

Congratulations, Arun, I think you've found a bona fide bug in Red Hat's crontab (it isn't present on Ubuntu 12.04LTS, though that's the only other system I have to hand for testing). Do you want to log it with with RH bugzilla, or shall I?

4
  • Got a link for the bug report ?
    – user9517
    Oct 5, 2014 at 15:20
  • I don't think Arun's said whether or not he wishes to log it, yet. If you're asking whether someone's already found this, I haven't yet looked (though I would before logging it, if Arun decides he'd rather I did it).
    – MadHatter
    Oct 5, 2014 at 15:22
  • Arun asked you to file the bug. I had a cursory look earlier and didn't see anything but it could be there.
    – user9517
    Oct 5, 2014 at 15:35
  • Thanks, Iain; I hadn't been looking up for edits in the question. I'll do it in the morning. Arun, feel free to accept one of the answers to this question, so that it doesn't hang around forever like a querulous albatross.
    – MadHatter
    Oct 5, 2014 at 20:30
1

Replace 24 with 0 (which is 24), as for second entry, last job would run 21:30.

You can also try this:

30 0,6,9,12,15,18,21 * * * /path/to/script

full syntax:

# cat /etc/crontab 
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed

# 
2
  • Or 30 0,6-21/3 * * * /path/to/script, which seems valid with Vixie cron.
    – MadHatter
    Oct 2, 2014 at 19:57
  • right, that is also correct syntax.
    – alexus
    Oct 2, 2014 at 19:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .