Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!olivey!jerry From: jerry@olivey.olivetti.com (Jerry Aguirre) Newsgroups: comp.sources.d Subject: Re: v23i028: A cron/crontab replacement, Part01/01 Summary: DOM/DOW combinations broken Message-ID: <49594@olivea.atc.olivetti.com> Date: 13 Oct 90 03:17:30 GMT References: <2878@litchi.bbn.com> Sender: news@olivea.atc.olivetti.com Lines: 76 In article <2878@litchi.bbn.com>, rsalz@bbn.com (Rich Salz) writes: > Submitted-by: Paul A Vixie > Posting-number: Volume 23, Issue 28 > Archive-name: vixie-cron/part01 > > X-- the dom/dow situation is odd. '* * 1,15 * Sun' will run on the > X first and fifteenth AND every Sunday; '* * * * Sun' will run *only* > X on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this > X is why we keep 'e->dow_star' and 'e->dom_star'. I didn't think up > X this behaviour; it's how cron has always worked but the documentation > X hasn't been very clear. I disagree that it has always been that way (whatever "always" means) and most strongly disagree that it should be that way. Don't take this as completely critical. I like the idea and the code. On our 4.3BSD systems we set up our level 0 dumps to run early Monday morning. Because several systems are using the same Exabyte one system dumps on the first Monday of the month, another on the second Monday, and so on. This is very easy to do with the 4.3BSD cron. To dump on the 1st Monday the entry looks like: 30 0 1-7 * 1 root /usr/etc/autodump When I added this to a Sun running the per-user crontab I got some very strange results. Eventually I found the above mentioned behavior documented in the man page. I can offer two reasons why I think this behavior is wrong. The first is that while the previous man pages may not have explicitly specified the behavior it was implicit in the treatment of the other fields. One does not expect: 0 2 1 * * /etc/monthly to execute at 2 AM every day and at every hour all day of the 1st! While the day of month (DOM) and day of week (DOW) allow two different ways of specifying the day the implication is that all fields must be true for the command to run. As a second reason I ask which is the more practical interpretation. To achieve the effect of running on the both DOM and the DOW one can simply add two crontab entries: 0 2 1 * * /etc/monthly_monday 0 2 * * 1 /etc/monthly_monday Pretty simple. Of course this seems like a pretty useless combination anyway. Is there anyone out there that runs anything using such a combination? On the other hand if one assumes the "both DOM and DOW" interpretation it makes scheduling things for the first Monday of the month rather painful. I now have 12 crontab entries specifying the month and DOM for each of the coming 12 months. A 13th entry sends me mail to remind me to update this kludge for the next year. Most people do work on a weekly schedule and scheduling for the Nth day of the week for each month is common; Look at any accounting calendar. I suggest that whoever originally wrote the new version mis-understood the code and "fixed" the result by documenting the bizarre behavior. It provides a useless feature at the expense of breaking a useful one. Does anyone know the history of cron sufficiently well to corroborate this? Let me again add that I like the other features of the program and in particular the concept of a per-user crontab. Jerry Aguirre P.S. Yes, the systems are single user when the level 0 dumps are done. The script starts a shutdown with reboot and during the reboot the file systems are dumped before going multi-user. The operator arrives, verifies that the system is multi-user again, and then takes the ejected tape to storage.