Using the following crontab: 21 11 5-15 * Thu echo test1 21 11 5-15 * Fri echo test2 Yields the following result: Jan 10 11:21:01 pie /USR/SBIN/CRON[14172]: (chrisb) CMD (echo test2) Jan 10 11:21:01 pie /USR/SBIN/CRON[14175]: (chrisb) CMD (echo test1) In other words, the day-of-week value seems to be ignored. If I replace day-of-month with '*', I get the expected behaviour.
#460070 - cron: Using day-of-month and day-of-week together doesn't work as expected http://bugs.debian.org./460070 Hi Chris, |Note: The day of a command#s execution can be specified by two fields # |day of month, and day of week. If both fields are restricted (i.e., |aren#t *), the command will be run when either field matches the cur# |rent time. For example, |##30 4 1,15 * 5## would cause a command to be run at 4:30 am on the 1st |and 15th of each month, plus every Friday. So I think this is a non-bug ?
Well, the documentation does describe the behaviour as it stands, but the problem is that it makes certain rules impossible to define. The current behaviour "set up a job that runs every day between the 5th and the 15th, plus every friday" could also be set up as two separate rules, whereas it is impossible to set up a job to run "every Friday between the 5th and the 15th". Plus the current behaviour is a bit inconsistent. The other fields are combined with a logical AND (ie: month AND day of month AND hour AND minute), whereas the day of month and day of week fields are combined with a logical OR.
But it's probably standard, documented behavior since 1970 so not reasonable/possible to change. The best way I can think to get the desired behavior is: 0 0 5-15 * * [root] [ "`date +w`" -eq 5 ] && ... which is not so bad: requires some extra time to think about that can be alleviated with a comment, and requiers an extra shell process and test 1/7 times when the "real" command won't be run.
I have the same problem. Do you know if its going to be fixed (added feature) in future?
Its not a bug (man 5 crontab), Its only a "bizarre behavior" -> Paul Vixie says in cron.c code file:
/* the dom/dow situation is odd. '* * 1,15 * Sun' will run on the
* first and fifteenth AND every Sunday; '* * * * Sun' will run *only*
* on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this
* is why we keep 'e->dow_star' and 'e->dom_star'. yes, it's bizarre.
* like many bizarre things, it's the standard.
*/
I was writting a "php scheduler" when i found this useless behaivor.
* Solutions:
- A "bash trick". Justin Pryzby suggestion. For example: { [ "`date +w`" -eq 5 ] && command }, only execute the job on Friday.
Its good, but it breaks the sintaxis consistency for me, and its "pretty/more difficult" to develop an harmony code parser.
- The other solution is to change the native behaivor, patching the cron code.
Yes, I know its not the standard, but cron will work in a "logical mode".
I´ve coded a simple patch (attached) for me and for that people who need to change it, and then, when you put this in crontab:
* * 1,15 * Fri echo "el nene llora poco"
The "echo" will only be executed on 1 And 15 every month, ONLY if the day of the week is Friday.
-
Jesús Feliz Fernández (janzun@rosanegra.org)
severity 460070 wishlist tag wontfix thanks As many have indicated here, this behaviour is standard. I don't like it either, but that's the way it is. Anyway, there are easy workarounds for this (see Justin's shell trick, for example). Because Jesús was kind enough to provide a patch, I'm keeping this open as a wishlist item. We may implement this via a CLI flag (eg --nonstandard) in the future. Christian
The above patch by Mr. Feliz changed the semantics of crontab by making cron AND the dom and dow fields instead of the default OR-when-not- star. This would be more consistent overall, but that ship has sailed decades ago. Interestingly, the cron on early versions of UNIX [1] doesn't seem to have that behavior but the "normal" one (it might have been a bug in the scheduling). Although some time later it got clearly spelled on SUSv2 [2] (probably on v1 as well), and Vixie even defines it as a "bizarre" but "it's the standard". With the odd behavior set in stone, using day-of-month and day-of-week together (which would be useful, as already shown on this bug) requires using a syntax which doesn't conflict with the previous one (that SHALL keep working as-is). The attached patch allows adding an optional '&&' token (surrounded by whitespace) before the day of week field to mark that the day of week of this line must match *in addition* to the day of month field. Since it's a per-entry marker, lines ANDing the fields and ORing the fields can be freely mixed in the same file. As a counterpart to &&, a '||' token is also recognised at the same place although it's a no-op merely for presentation purposes, since it "selects" the default behavior (marking entries with dom and dow can be useful as an explicit reminder of the dow gotcha). The original crontab would look like this 21 11 5-15 * && Thu echo test1 21 11 5-15 * && Fri echo test2 which is much nicer than the date tests embedded in the command The patch is also available at https://salsa.debian.org/Angel-guest/cron/-/tree/bug460070 Regards [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cron.c https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/cron.8 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/cron.c https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man8/cron.8 https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/cmd/cron.c [2] - https://pubs.opengroup.org/onlinepubs/7908799/xcu/crontab.html