1

Here is the job, intended to run every 15 minutes between 7AM and 7PM:

*/15 07-19 * * * /home/max/bashScripts/rsyncMe >/dev/null 2>&1

The job is running every 15 minutes every hour instead, i.e., it runs from midnight to 23:45.

The job itself completes in under 5 minutes each time it is started.

The OS is Debian-Buster. Cron is up to date.

What might be the cause of the problem.

8
  • 2
    Does it work without the leading 0, as 7-19? Obviously it should work as 07-19, but I never saw an example with leading zeros, and I have a vague recollection this issue has been seen before. (Clutching at straws!) – Paul_Pedant Dec 1 '20 at 21:42
  • 1
    Also this is helpful: crontab.guru – thanasisp Dec 1 '20 at 21:51
  • A leading 0 often means "this is octal." I don't know if they use the standard C library to parse, but that could be it... – Aaron D. Marasco Dec 1 '20 at 22:06
  • 1
    @AaronD.Marasco, except that here the number is 07, which is the same in octal and in decimal – ilkkachu Dec 1 '20 at 22:51
  • it is parsed in entry.c, get_listget_rangeget_number, which ends up doing an atoi. No reason this should fail... – Ángel Dec 1 '20 at 23:25
3

The valid hours range is 0-23, so you should use

*/15 7-18 * * *

to run every 15 minutes from 07:00 (first run) to 18:45 (last run) every day.


The leading zero for the hour range (07) was the cause for the hour field to be assumed as *. I tested (cronie-1.5.1-lp151.4.6.1.x86_64 on suse) that the behaviour is same to your description, for a range, like * 01-02 * * * but it unexpectedly worked correctly for a single value: * 01 * * *. So, I wouldn't dig it more, we just don't use leading zeros there.

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.