jjb@zeus.cs.wayne.edu (J. Brewster) (05/18/89)
I just noticed yet another odd effect of the R option to sendmail... we're running 4.0 on a bunch of Sun-3's, with mailboxes served from a single fileserver, and mounted on both Sun clients and DEC clients. I used the OR option on the Sun clients to cause all messages to be routed to the server, and modified the sendmail.cf file on the DEC machines to do the same thing. That has worked fine for many months. After installing Usenet news software, I discovered that the mail messages generated by Rnmail, while they do seem to get delivered, leave copies of the df* file around, plus empty lf* and xf* files. Any similar invocation of "/usr/lib/sendmail -t < file" does the same thing. Eliminating the OR option from sendmail.cf and rewriting ruleset 0 to route all messages to the mailhost causes this condition to cease. J. Brewster | "In this country, everything loose jjb@cs.wayne.edu | rolls to the West Coast." ...!mailrus!wsu-cs!jjb | --Thomas A. Vanderslice, CEO of Apollo
stanonik@nprdc.navy.mil (Ron Stanonik) (05/18/89)
I've been wondering what happens when the server is down or even just busy. Since the machines with R option are presumably not running a daemon, queueing makes no sense; ie, no daemon to later run the queue. Does sendmail with the R option notify the user of the problem, quietly lose the mail, ...? Could some of the artifacts be left over because the server was unavailable? Thanks, Ron Stanonik stanonik@nprdc.arpa ucsd!nprdc!stanonik
beau@ames.arc.nasa.gov (Beau James {Manager - SW Development - Ultra Networks}) (05/25/89)
--> I've been wondering what happens when the server is down or even just
--> busy. Since the machines with R option are presumably not running a
--> daemon, queueing makes no sense; ie, no daemon to later run the queue.
--> Does sendmail with the R option notify the user of the problem, quietly
--> lose the mail, ...? Could some of the artifacts be left over because the
--> server was unavailable?
At least on SunOS 4.0.1, sendmail on the client goes into an infinite
retry loop, attempting to connect to the server, getting "Connection
refused" or similar failures each time. This continues until the sendmail
daemon on the mail server returns to life to accept the mail.
Can you say, "Peg my client CPU?"
In a large percentage of cases, the mail server and the diskless client's
server are the same machine, so the client tends to be hung anyway when
sendmail is not available on the server. But if the mail server and disk
server are different machines, or if sendmail is disabled on the disk
server for other reasons, the client loses.
The real performance lose is delivering mail to diskless clients. It's an
expensive way to get the bits onto the server's disk. Most of the
performance gain can be had by delivering mail on the server, but still
running the sendmail daemon on the client, so that the mail can be queued
on the client if undeliverable. As long as mail is being delivered on the
mail server, the client sendmail daemon will rarely be invoked. It will
end up swapped out, consuming minimal system resources.
Beau James beau@Ultra.COM
Ultra Network Technologies {sun,ames}!ultra.com!beau