Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!CAEN.ENGIN.UMICH.EDU!markg
From: markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo should use sendmail internally
Message-ID: <468ab95f3.0017b5e@caen.engin.umich.edu>
Date: 30 Oct 89 19:36:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 36


	Does each node then have an /etc/spool/mail directory and a sendmail
	daemon running?  Otherwise case (2) and (3) can't spool up the mail if
	the central mail machine is down.  A similar problem occurs for case
	(1) if you use links to find the alias file. [This is another good
	example of why the operating system should provide some kind of
	"redundant link".]
	 
	And this still doesn't address the problem with file locking across
	nodes: touching your mail spool file from a node other than that where
	the spool directory lives may break sendmail, causing the mail to be
	returned to sender (or worse).

Actually we at UofM(CAEN) link all our spool dirs to a central machine.  Its six
of one or half a dozen of another.  Either the big one is down or some of the
small ones are down.  It teaches you to keep an eye on your primary server. 
This is actually the best scenario for a large Apollo ring.  When the server is
down, then mail trying to be delivered *should* be temporarily queued (i.e.,
/bin/mail returns a code that tells sendmail to "leave it queued").  The same
for when the file is locked.  Actually, we put in our own open which will wait
up to 15 seconds for the mail file to unlock before returning the "leave it
queued" return code to sendmail.

The current behavior of Unix sendmail (to repeat an earlier msg) is for
/bin/mail to balk at the locked file and return to sendmail which returns to it
to the sender with "unknown mailer error" msg.  /bin/mail presumes it can always
connect to the mailbox which is wrong in an Apollo or NFS environment.

Remember that queuing a msg because it cannot be delivered is not a bad thing.
Presumably you run "/usr/lib/sendmail -q" from cron on every node every 30 or
60 minutes that will process any queued mail.  This way, these temporary problems
are just that, temporary.

Mark Giuffrida
Univ of Michigan
markg@caen.engin.umich.edu