2

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!) Dec 1, 2020 at 21:42
  • 1
    Also this is helpful: crontab.guru
    – thanasisp
    Dec 1, 2020 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... Dec 1, 2020 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, 2020 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, 2020 at 23:25

1 Answer 1

4

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.

You must log in to answer this question.

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