tag 625498 + unreproducible moreinfo On 05/03/2011 11:06 PM, Karl O. Pinc wrote: > Files in /etc/cron.d that have group write permissions will > not have their cronjobs run but if /etc/cron.d/ contains > a symlink to a file with group write permissions the cron > jobs in that file are run. After the content of the file > is changed cron will then refuse to run the jobs. > > The following script demonstrates the problem: > > ---------------------<snip>----------------- > # Tidy up before we start. > rm -f /etc/cron.d/foo /tmp/foo > sleep 60 > > # Establish crontab > cat - >/tmp/foo <<EOF > * * * * * root printf 'Running\n' > EOF > chmod g=w /tmp/foo ^^^^^ see below
> > ln -s /tmp/foo /etc/cron.d/ > > # Permissions are: > ## ls -lh /tmp/foo > #-rw-r--r-- 1 root root 34 May 3 10:56 /tmp/foo > > sleep 60 I believe you made an error here, as it should be rw-w--r-- after the chmod above. If it indeed was rw-r--r-- at startup, it explains why cron picked it up; and if the mode changed afterwards, we're back at #625495: mtime triggers rescan -> bad mode -> drop from db -> no rescan > # Cron job runs (email delivered to root) > > cat - >/tmp/foo <<EOF > #* * * * * root printf 'Running\n' > EOF > > sleep 60 > > # Cron job does not run > > cat - >/tmp/foo <<EOF > * * * * * root printf 'Running\n' > EOF > > sleep 60 Could you confirm this for me? Christian
signature.asc
Description: OpenPGP digital signature