[ale] RHL9 crond doesn't read in new crontab entries
jjj863 at gmail.com
Tue Aug 22 13:07:28 EDT 2006
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:".
> > 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
More information about the Ale