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.
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)?
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.
> > 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.
> > 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?
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
