You can close and discard this bug report. It's wrong, and
what's not wrong is covered by other bug reports.
Thanks for your patience.
On 05/07/2011 06:32:14 PM, Christian Kastner wrote:
> 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
>
>
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
