Original message:
> Can anyone offer a reason why we might be getting the following errors?
>
> from /var/log/syslog:
>
> Apr 24 17:01:02 unisql sendmail[17622]: AA17622: SYSERR: net hang reading from lamborghini: Connection timed out during collect with lamborghini
> Apr 24 17:01:02 unisql sendmail[17622]: AA17622: message-id=<9104242146.AA17622@unisql.unisql>
> Apr 24 17:01:03 unisql sendmail[17622]: AA17622: from=<carando>, size=6649, class=0
> Apr 24 17:00:58 lamborghini sendmail[4304]: NOQUEUE: SYSERR: net hang reading from unisql: Connection timed out
>
> from /var/adm/messages:
>
> Apr 24 17:01:02 unisql sendmail[17622]: AA17622: SYSERR: net hang reading from lamborghini: Connection timed out during collect with lamborghini
> Apr 24 17:00:58 lamborghini sendmail[4304]: NOQUEUE: SYSERR: net hang reading from unisql: Connection timed out
>
... gory details omitted ..
I got a number of suggestions early on that didn't apply to our situation (but
I will summarize here in case they might be of use to someone else):
o missing newline at end of user's .signature
o bogus /etc/passwd entries
Three people offered variations on a theme involving lost SMTP connections and
the sendmail OR option. I'm going to give each of the proposed solutions a
week's run in our environment and pick the one that works best for us, so I
can't say yet which will best cure our problem (assuming at least one of them
does, of course ;-), but the argument sounds like the correct analysis of the
problem, so I will pass it on here along with the proposed solutions.
The problem:
> We've had this problem since 4.0. The problem is that ... sendmail
> occasionally hangs when communicating mail from a client to the mail server.
> Since you are running the clients without sendmail as a daemon, it just sits
> around on the port. It keeps trying to send the mail, and each time it does it
> mallocs more memory ... Eventually, it can't malloc anymore and dies. This is
> when you get the error message, and this is when your mail is effectively lost
> (up to that point, it is hanging around in /tmp). ... [This] has been reported
> to Sun, and there is even a bug ID for it ...
The first proposed solution:
> Try the following: in your /etc/fstab add the actimeo option:
>
> server:/var/spool/mail /var/spool/mail nfs rw,hard,actimeo=1,intr 0 0
>
> and make sure you have the "OR" option for all machines in your
> /etc/sendmail.cf file.
The second proposed solution:
> I definitely recommend using one of the minimalist sendmail.cf's for this
> purpose that has been floating around the net instead of the OR option. The
> only inconveniences with this are that you have to actually spell out the
> name of the mailhost, and that you have to make sure the client's queue is
> checked - if you don't want to run a daemon (which I think is the best
> solution - the load from this should be neglible), you can have sendmail -q
> run from crontab e.g. hourly. On the other hand, you can use the same
> sendmail.cf on non-Sun mail clients.
>
> I have done just this, using essentially the version that Rich Salz sent out on
> comp.mail.sendmail a while back ... and all of the problems went away.
One response included a list of the bugs/problems with Sun's OR sendmail.cf
option that he'd found to date:
> 1. If the connection between client and server sendmail is broken during
> the DATA phase (i.e when the actual letter is transferred), the letter
> is lost, without any information to user or Postmaster, the only trace
> is a "SYSERR: net hang reading from..." type of message in syslog.
> (In addition, it appears that the connection breaking like this happens
> rather more than would be expected due to "natural" causes.)
>
> 2. Anyone can fake sender addresses with sendmail -f.
>
> 3. Sendmail -t forgets to remove temp file (fixed post-4.0.3, I believe).
>
> 4. Sendmail -t called from emacs (actually whenever it can't do a
> getlogin()) with a local recipient address will put the *recipient*
> address in the From: line.
>
> 5. If a sendmail deamon is run (e.g. if you want to be kind enough to handle
> the occasional mail mis-addressed to user@client rather than having it
> sit in some queue for several days before being bounced), it will ignore
> the OR option, and happily do local delivery causing /bin/mail to write
> /var/spool/mail via NFS, or send directly to hosts in the YP map while
> setting the sender address to user@client. In addition, the local
> delivery is somehow half-baked, ignoring e.g. .forward files.
>
> 6. Since (in the normal non-deamon case) the sendmail.cf apart from OR is
> essentially ignored, it isn't possible to do *any* host-specific
> handling, e.g. splitting up mail to root depending on which client
> generated it.
>
> 7. If the mailhost isn't reachable, each letter sent will cause the
> corresponding sendmail process to sit in a loop doing repeated attempts
> - apart from the load, this means that if the client is shut down or
> rebooted before successful delivery, the mail is lost.
>
> 8. It doesn't work at all if /var/spool/mail is auto-mounted.
>
> 9. Sendmail -t will remove one empty line between header and body, with
> the effect that initial body lines that have leading whitespace, or
> that start with <word>:, are moved to the header.
>
> 10. Sendmail -t where the destination is a local alias will generate a
> "User unknown" error message (although the letter will be delivered
> correctly) - if PostmasterCopy is in effect, there will (of course)
> be an additional "User unknown" for Postmaster.
>
> I realize that 6 and 7 are consequences of intentional design decisions, and
> that 5 might be considered operator error; I still consider them deficiencies.
**********************
Many thanks to:
barnett@pluto.crd.ge.com Bruce Barnett
lsf@astrosun.TN.CORNELL.EDU Sam Finn
geertj@ica.philips.nl Geert Jan de Groot
per@erix.ericsson.se Per Hedeland
brendan@cs.widener.edu Brendan Kehoe
{uunet,boulder}!chs!danq Daniel Quinlan
syd@DSI.COM Sydney S. Weinstein
--
alfred
Internet: execu!sequoia!unisql!alfred@cs.utexas.edu
UUCP: {uunet, cs.utexas.edu!execu}!sequoia!unisql!alfred
It is better to have a horrible ending than to have horrors without end.
-- Matsch's Law
The sooner you fall behind, the more time you will have to catch up.
-- Stenderup's Law
Teamwork is essential ... it allows you to blame someone else.
-- Finagle's Eighth Rule
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:13 CDT