Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!im4u!milano!mcc-pp!ables
From: ables@mcc-pp.UUCP (King Ables)
Newsgroups: comp.unix.questions
Subject: Re: How to make sendmail re-read the configuration file (and cron)
Message-ID: <2409@mcc-pp.UUCP>
Date: Mon, 19-Jan-87 20:36:06 EST
Article-I.D.: mcc-pp.2409
Posted: Mon Jan 19 20:36:06 1987
Date-Received: Tue, 20-Jan-87 19:30:30 EST
References: <136@quacky.mips.UUCP> <201@devon.UUCP>
Distribution: na
Organization: MCC, Austin, TX
Lines: 31

>> I would like to modify sendmail to have it re-read the configuration

> Why not do what cron(1) does.  Perform a stat() call on the file's fd
> after it is first opened and save the st_mtime value somewhere (the
> last modification time of the file).  Then have sendmail re-stat the
> file every time it is awakened, compare the new st_mtime value with the
> saved one, and if the new one is greater (the config file has been
> modified since the original read), re-read the file.

Ah-ha!  That's just solved a problem for me.  I've got a bunch of
diskless suns and rather than have a different crontab for all
the suns on a server, I have all clients crontabs point to the
real crontab file.  However, when I make a change, it doesn't seem
to take unless I kill the cron daemon.  I never even thought of
stat()!  Of course, it's stat()ing the symbolic link (which hasn't
changed!) and not the real file.

Now, the question I have is why would you ever NOT want stat()
to resolve the link and stat the actual disk file rather than the
link???  And is there a way I can solve my problem short of
killing cron on all suns and restarting it or removing the link
and making a new one in its place (which would, of course, have
today's date)?  I tried a touch on the link, but of course,
touch resolves the link and touches the real file!!  **arghh!!**

-King
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!mcc-pp!ables
-------
Michael: Women!
Larry:   Yeah.  Can't live with 'em... can't stuff 'em in a sack!