Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: How to make sendmail re-read the configuration file
Message-ID: <5148@mimsy.UUCP>
Date: Thu, 22-Jan-87 12:46:21 EST
Article-I.D.: mimsy.5148
Posted: Thu Jan 22 12:46:21 1987
Date-Received: Thu, 22-Jan-87 21:44:50 EST
References: <136@quacky.mips.UUCP> <5021@mimsy.UUCP> <194@dgis.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 23

In article <194@dgis.UUCP> generous@dgis.UUCP (Curtis Generous) writes:
>... sendmail can be forced to read the configuration file by performing
>the following steps:
> 
>	cp /dev/null /usr/lib/sendmail.fc  # erase old frozen configuration
>	/usr/lib/sendmail -bz		   # which reads the new configuration

This tells sendmail to *rebuild* the frozen configuration file, which
affects any new `sendmail's run.  Alas, the background daemon that
periodically scans queued mail and that accepts incoming SMTP mail
never notices the change.

Adding a stat() call and rereading the configuration would be quite
tricky, as the frozen configuration is simply a memory dump of the
entire data segment.  There are only a few places where it is safe
to read this.  Easier would be to have sendmail exec itself, somehow
telling itself which file descriptor is the SMTP socket.  The
biggest problem with the method we use here (kill the daemon nightly
and then start a new one) is that, due to vagaries of TCP, sendmail
sometimes has trouble re-acquiring the SMTP port.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu