On Fri, Apr 23, 2010 at 02:45:45PM +0200, Christian Kastner wrote:
> 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).
I don't quite see how these two things need to be handled the same way. In
#378153, the problem was cron executing some completely broken cron.d file
(a binary file). A specific typo in a specific field is not the marker of
a completely broken cron.d file.
> 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.
I do not believe it's good for a system to assume that root has a high level
of diligence :) The usual recourse of programs against simple mistakes is a
more or less rude error message, but in this case even this was omitted,
which is against the Unix philosophy of running silently if everything is
okay, and treating output as possible complaints. (See below...)
> > 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.
Yes. Perhaps advocate a local prefix or suffix in the documentation.
I name my files local-* to make sure I don't overlap with any new package
files. These would normally be caught by dpkg conffile prompts, but still.
> >>> 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.
I'm guessing this is the problem - it reads the change once (after the
file's timestamp/size change), it barfs, and then it keeps ignoring the
unchanged file with a broken line until you touch it again.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
