Hi Christian, Christian Kastner wrote: > thanks for your detailed bug report!
You're welcome. :-) > On 05/25/2011 12:40 AM, Axel Beckert wrote: > > It seems to be a more seldom and not yet fixed special case of the > > otherwise fixed http://bugs.debian.org/555954. As parts of #555954 > > definitely have been fixed, I decided not to reopen #555954 but file a > > new bug report and just refer to #555954. > > That, and #625495, a fix for which is currently pending. For the > curious, [0] provides a detailed explanation of what is causing this. > > I initially considered merging this report with #625495, but then > realized that the pending fix only recovers from filesystem errors (mode > etc), not from syntax errors (missing newline). > > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625495#10 > > > Now fix the missing newline in test1 by adding it again. It still won't > > run the cronjobs in there until you either: > > > > * Edit _another_ file in /etc/cron.d/, e.g. test2 > > Hm, this one is strange. I tested this several times, and at least with the script, I'm quite sure that it wasn't a *.swp or *~ backup file being created by the editor (i.e. changing the directory's inode). I also checked with "ls -li" that overwriting a file with ">" does not remove the old file and create a new one in my shell (zsh), but really just overwrites the file, i.e. the inode number does not change and the directory's mtime does not change either. > > * Create a new in /etc/cron.d/, e.g. test3 > > * Delete a file from /etc/cron.d/, e.g. test2 > > * Restart cron. > > > IMHO cron should at least stat files in /etc/cron.d with known syntax > > errors every time and recheck their syntax if the mtime has changed, not > > only if other (valid) files have changed, vanished or popped up. > > This is a great idea. I couldn't do that for the mode errors recovery > because they don't change mtime, but fixing a syntax error would. Please also take care that the new mtime may be lower (earlier) than the one cached. This can be the case if you edit (or break :-) a file locally to test something and it gets overwritten with an older config file put there by your favourite configuration management tool. E.g. wget can modify the mtime of a downloaded file to match the Last-Modified time stamp, the webserver sent as HTTP header. > I'll extend the recovery fix to do that. Thanks! > > So to be sure that I run the test without the danger of collateral > > changes, I fully automated it. See script, syslog and output below. > > I haven't run it yet, but will use it to verify the fix. Would be curious if you find out what logic causes the "edit another file" thing to work. :-) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
