dce@mips.UUCP (David Elliott) (01/08/87)
In our environment, it is possible for the sendmail configuration file to change much more frequently than a machine is rebooted. I looked at the code for sendmail, and could only find one place where it reads the configuration file (in main()), and no way to send a signal or message saying "re-read the configuration file". This means that we have to kill the daemon and restart it manually (or at best by finding the pid using ps, killing it, and restarting it with the right arguments). I would like to modify sendmail to have it re-read the configuration file on some given signal (HUP?), but I am worried that sendmail can't handle this without modifications elsewhere. Is there anyone with a lot of sendmail experience that can help me out? David
israel@brillig (Bruce Israel) (01/10/87)
In article <136@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: > >In our environment, it is possible for the sendmail configuration file >to change much more frequently than a machine is rebooted. > >I would like to modify sendmail to have it re-read the configuration >file on some given signal (HUP?), but I am worried that sendmail >can't handle this without modifications elsewhere. Is there anyone >with a lot of sendmail experience that can help me out? I've been wanting such a signal myself, but haven't looked into adding one. We also have tables that the sendmail.cf file uses that are updated on a nightly basis. As a result, what we do is have a line in crontab that looks like: 30 2 * * * root cd /usr/lib/hostnames/bin; /usr/local/bin/user bin /bin/make; kill `ps aux | egrep '/usr/lib/sendmail -bd -q15m' | awk '{print $2}'`; /usr/lib/sendmail -bd -q15m & It's ugly, but it works. Every night at 2:30am, cron updates all necessary tables then kills off and restarts the daemon. Bruce Israel University of Maryland, Computer Science Dept. {rlgvax,seismo}!umcp-cs!israel (Usenet) israel@Maryland (Arpanet)
bzs@bu-cs.BU.EDU (Barry Shein) (01/11/87)
Re: making sendmail re-read cf file on signal... Assuming it's a hard thing to add, how about just a 10 line C program which fork/execs sendmail (in a process group) and waits for the signal. When received kills its child and starts another fresh one. Not entirely sure what the advantage is over just killing and rerunning the sendmail unless you're worried about the small window in which there is no daemon running. I guess the little hack above could put its pid into a file or something making it easier to find (mqueue/.pid). Maybe just teaching sendmail to re-exec itself on receipt of a signal would be sufficient (or have it squirrel away the change date of the .cf file and re-exec on that updating, have it check as it starts each q run.) Just thinking out loud. -Barry Shein, Boston University
paul@devon.UUCP (Paul Sutcliffe Jr.) (01/15/87)
In article <136@quacky.mips.UUCP>, dce@mips.UUCP (David Elliott) writes: > I would like to modify sendmail to have it re-read the configuration > file on some given signal (HUP?), but I am worried that sendmail > can't handle this without modifications elsewhere. Is there anyone > with a lot of sendmail experience that can help me out? 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. -paul -- Paul Sutcliffe, Jr. UUCP: {seismo,ihnp4,allegra,rutgers}!cbmvax!devon!paul Devon Computer Services COMPUSERVE: 76176,502 Allentown, Penna. "I love work ..." +1 215 398 3776 "... I could sit and watch people do it all day!"
ables@mcc-pp.UUCP (King Ables) (01/20/87)
>> 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!
chris@mimsy.UUCP (Chris Torek) (01/20/87)
In article <2409@mcc-pp.UUCP> ables@mcc-pp.UUCP (King Ables) writes:
<... 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.
That is rather strange if it is.
<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???
Why? Suppose you want to find out about the link. In this case,
use lstat(), which does not follow the link. The stat() call does
indeed follow symbolic links `and stat the actual disk file'.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.eduekrell@ulysses.homer.nj.att.com (Eduardo Krell) (01/20/87)
In article <2409@mcc-pp.UUCP> ables@mcc-pp.UUCP writes: >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??? stat() always follows symbolic links; lstat() does not. You need lstat() to see what the permissions are on (and who owns) a link, for instance. Unless programs use lstat(), they will follow symbolic links and will be unaware of their existence. -- Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
andrew@hammer.TEK.COM (Andrew Klossner) (01/21/87)
[]
"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???"
Something's wrong. The 4.2BSD definition of stat(2) says that it gives
the status of the file to which the symlink points. The lstat(2) call
gives the status of the symlink itself.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(tekecs!andrew.tektronix@csnet-relay) [ARPA]generous@dgis.UUCP (Curtis Generous) (01/21/87)
In article <136@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: > >I would like to modify sendmail to have it re-read the configuration >file on some given signal (HUP?), but I am worried that sendmail >can't handle this without modifications elsewhere. Is there anyone >with a lot of sendmail experience that can help me out? I don't acknowlegde knowing very much about sendmail, but on our machine (a VAX 780, running 4.2BSD), 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 -curtis- Curtis C. Generous Lawrence Livermore National Labs generous@lll-tis-b.ARPA ...!{seismo,vrdxhq}!dgis!generous
davel@hpisoa1.UUCP (01/22/87)
Re: making sendmail re-read cf file on signal...
I wrote a script which sits in a loop doing a ps and waiting for the
sendmail daemon to go idle. Then it kills and restarts it. There's
still a race condition, of course. (Between the ps that shows an
idle sendmail and when the script executes the kill command.)
Dave Lennert ucbvax!hpda!davel [UUCP]
Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP]
19447 Pruneridge Ave. hpda!davel@Berkeley.edu [ARPA]
Cupertino, CA 95014 (408) 447-6325 [AT&T]chris@mimsy.UUCP (Chris Torek) (01/22/87)
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
mp@allegra.UUCP (01/26/87)
As for the original question, the folks at ulysses run /usr/lib/sendmail -bs from inetd. You then need to put calls to /usr/lib/sendmail -q in crontab, but this isn't such a bad idea anyway, since for some reason it results in far fewer hung sendmail processes compared to sendmail -bd -qxxxm. As for ables@mcc-pp's question about cron not noticing changes in a shared crontab, I think the problem may be due to the caching in ND. (I'm presuming that the shared copy is in /pub, not in an NFS partition; we have the same problem with our shared /usr/lib/aliases, which lives in ND rather than NFS so that we can control access to it). Modifying cron so it doesn't keep /usr/lib/crontab open all the time, and periodically flushing the clients' disk caches should help. We've found "du /pub" - we have several thousand files in our /pub - and a couple "umount /pub"'s (umount will fail, of course, but it does what we want) usually flush the cache. Mark Plotnick allegra!mp