Josip Rodin wrote: > 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.
Indeed, it isn't. The second approach, however, involves a whole lot of new code for something that should never be an issue in the first place (see below). >> 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 :) Neither do I (by experience), but that's the way things are. root -- by definition -- enjoys absolute trust, and if that trust is placed in the wrong hands, there's not much we can do about it. In our case, we acknowledge the error and log to syslog. Let me give you another example: this is also why we allow symlinks in /etc/cron.d. Because only root can create those, we simply assume (again) that root knows what she's doing. We just before some basic checks on the target, such as ownership and permissions. I believe that watering down this level of trust for the sake of the trust-unworthy would be misguided. > 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...) Agreed. >>> 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. I've taken note of this, thanks. >>>>> 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. Yes. This is a side effect of a power-management-related feature, indented to reduce disk spin-ups on laptops. Christian -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
