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

[Jerry Yu]

'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
>