[ale] RHL9 crond doesn't read in new crontab entries

[Jerry Yu]

download the vixie-cron-4.1.src.rpm for CentOS 4 and dug a bit more myself
1) cron.c : SIGHUP only calls log_close()
2) crontab.c: 'crontab -e' updates SPOOL_DIR's via utime() after
crontab file is changed for a user
3) cron.c calls load_database(cron_db) in database.c inside a big
while(TRUE) loop. load_database(cron_db) would attempt to  update
cron_db only if SPOOL_DIR's mtime different from the current cron_db.

so, it should have worked. hmmm...

On 8/22/06, Jerry Yu <jjj863 at gmail.com> wrote:
> 'crontab -e' always does the job for me under Solaris (2.6/7/9/10) and
> Linux (RHL4.2 - RHL9, RHEL 3-RHEL4). so, on this rare occasion, maybe
> just  the domain socket was somehow gone coo-coo, or its association
> with crond did.
>
> On 8/22/06, Danny Cox <DCox at icc.net> wrote:
> > On Tue, 2006-08-22 at 08:38 -0400, Chris Ricker wrote:
> > > You're not the only one
> > >
> > > I've seen similar on both Linux and on Solaris. Usually, it was either
> > > because of a weird interaction with a naming service or because of nscd
> > > (if you use nscd, start it before cron and never restart it without also
> > > restarting cron)
> > >
> > > One of the other Unix admins here is paranoid enough about this that he
> > > *always* restarts the cron daemon after editing any root crontab ;-)
> >
> >         Okay, I'll weigh in on this too.  I've long suspected that modern
> > cronds implemented another mechanism for notification besides kill -HUP
> > that Edition 7 Unix had (showing my age, huh? ;-).  I just did an "ls
> > -l /proc/1724/fd" on my system (crond's PID), and one interesting fd is
> > "4 -> socket:[4514]".
> >
> >         I speculate ('cause I've not read the code) that crontab may "nudge"
> > crond to reread a just-modified crontab via the socket.  That would also
> > explain why simply editing a crontab in place would have no effect;
> > crond never notices.
> >
> >         The current man page for crond says that a HUP will cause it to close
> > and reopen it's log file.  It mentions nothing about rereading the
> > crontabs.
> >
> >         Yeah, now my curiosity is up.  I'll have to download the source and
> > poke around at it.  Linux mysteries.  Blech! ;-)
> >
> > --
> > Daniel S. Cox
> > Internet Commerce Corporation
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
> >
>