Josip Rodin wrote: > On Fri, Apr 23, 2010 at 12:11:49AM +0200, Christian Kastner wrote: >>> I believe this problem just hit me too, on lenny. The issue here is that >>> cron will skip the execution of ALL jobs in a particular /etc/cron.d/file >>> if just one of them has an incorrectly formatted timing specification. >> Yes, this is intentional. > > This is something that should be *at least* made customizable. One does not > know whether jobs were put in the same file because they are co-dependent or > just because they made some loose logical sense to the admin to do it that > way. Things that we can be certain they are co-dependent are normally put in > the same script and run with a single cron line, two separate cron lines > define two separate jobs which can overlap etc, so it can't be immediately > clear that they are the same strict logical unit.
Yes, I agree, but that wasn't the intention. This restriction was introduced in 2006 after the gluck compromise (see #378153). Currently, it is assumed that because only root can modify /etc/cron.d, all files in there must be valid, due to root's higher level of diligence. One could argue about whether this is too restrictive, and whether one could at least partially run broken crontabs, namely the entries up to the first syntax error (these would hardly be a security issue). I would strongly disagree with this because, as said above, if there are broken crontabs in /etc/cron.d, you're doing something wrong. > At the same time, I see in cron(8) that this facility was invented for > packages, and: > > Like /etc/crontab, the files in the /etc/cron.d directory are monitored > for changes. In general, the admin should not use /etc/cron.d/, but use > the standard system crontab /etc/crontab. > > Why is this method out of favor for local changes (and only by documentation > and not in any way by the program)? Because /etc/cron.d was specifically invented for packages *only*. Having said that, I use /etc/cron.d for non-package stuff myself. LSB Core Chapter 20.1 isn't really clear on this, but I will review this issue when we move to upstream 4.1. > IMHO separate local files are clearly preferable because modifying > /etc/crontab means needlessly modifying a conffile, which means that a dpkg > conffile prompt can appear, providing a chance for an unwitting admin to > shoot himself (and/or other machine admins) in the foot. It has happened to > a co-admin of mine once. Yes, I agree. Nevertheless, this policy has been around since the 1990s, so a change -- even if only in documentation -- will take some review. >>> In my case I had made a typo in the day-of-month field and entered "38" >>> instead of "28". This was *not* actually reported anywhere, or at least >>> not anywhere I could see it, I only found it after manual inspection. >> Errors such as these are logged to syslog, eg: >> >> Apr 23 00:03:01 test cron[11556]: Error: bad hour; while reading >> /etc/cron.d/foo > There was no such thing in my logs. There was certainly no such thing every > hour, because I had the last N days of logs at my disposal and saw nothing > of the sort. This should not be. I tested the above message both on lenny and on sid before replying. Could you try to reproduce the issue and file a new bug if it persists? There might be something else going wrong. >>> As soon as I fixed that, the other job in the same file that runs >>> every fifteen minutes was magically reactivated. >> I added another log message to the processing code which explicitly >> states that the entire crontab will be disabled if it contains errors. > > Thanks. Will it show up whenever it is disabled, i.e. will I have a chance > to actually see the message post res? I'm not sure I quite follow, but generally speaking, the message will be logged to syslog once, after which logcheck or whatever can pick it up. Christian -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
