Very Computer

You probably also want to cut down the number of sendmail processes.
The best way to this is to have sendmail queue all the mail and deliver
it only on the queue runs (Odq).

4.11) TCP/IP connections time out too soon, especially on slow links.

    The tcp/ip abort interval in Solaris 2.x is too short,
    the default value is 2 minutes.  The result is that when an
    ACK isn't received in *2* minutes, the connection is closed.
    This is most often seen by sendmail, which will log

        sendmail: SYSERR: collect: read timeout on connection from ...

    You can fix this by running following command (e.g., at boot),
    which increases the timeout to 20 minutes (unit is millisec).

    /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 1200000

4.12) Solaris 2.x can't set up any TCP/IP connections to certain hosts.

    Solaris 2.x sets the don't fragment bit on all packets it send
    as part of MTU path discovery.  The Solaris 2.x implementation
    is RFC compliant, but the MTU path discovery protocol will
    fail when there are broken routers in the path.
    Typical symptom is not being able to connect from a
    Solaris 2.x hosts but having no trouble from other hosts.

    Workaround:

    /usr/sbin/ndd -set /dev/ip ip_path_mtu_discovery 0

    --- end of excerpt from the FAQ

Questions marked with a * or + have been changed or added since
the FAQ was last posted

The most recently posted version of the FAQ is available from
ftp.fwi.uva.nl in directory /pub/solaris

we had that problem on one of our 670s.  turned out a GID was
invalid in /etc/passwd, so the yp services were confusing
sendmail, causing it to hang.  fixing that GID caused the
problems to go away.

--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%  The Linguistic Tongue, AT&T  %%  C Code.  C Code Run.  Run, Code, RUN! %%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Hi,

This problem seems to have cropped up after sendmail ( Solaris 5.3 ) had been
installed on our remote site, and had been working just fine for a month or
so :-(

The symptoms are the following :

    (a) We get the following errors on the console window of the mailhost :

        ***

        SYSERR: net hang reading from <some host>
        Connection timed out during mail with <some host>

        ***

                OR

        ***

        SYSERR: net hang reading from <some host>
        Connection timed out during HELO with <some host>

        ***

        The <some host> in this case is a part of a network that we are connected
        to over a 64 kbps line.

        As a result of this, a lot of mail does not get to/from our remote site.

    (b) Local mail that is managed by the mailhost works out just fine.

    (c) Very often the mailhost has had as many as twenty to thirty sendmail
        processes active.  Each competing for time.

    (d) We have seen some problems with the 64 k line also giving us :

        ***

        Read error from network: Connection reset by peer

        ***

Our conclusions are that either ( or both :-( ) of the following are the problems :

(1) The 64 k line has intermittent faults, and hence the mail has difficulties
    getting to our site, while the remote host is trying to establish a connec-
    tion with the mailhost.

(2) The mailhost is simply being overwhelmed by the volume of mail that is being
    thrown at it.

The 64 k line seems to check out just fine when loopback tests are conducted
by the phone company, so some hardware/software fault ( router and/or modem )
at either end may be the actual problem.  We are looking into this.

Could some kind soul offer any insight based on the info that I have provided ?
Through our sendmail setup, we could control the number of sendmail processes
that are active at our mailhost at one time, but how can one regulate the
incoming mail ?  Is the problem that I have described a known "feature" of
5.3 sendmail ?  Is the only recourse adopting the Berkeley sendmail ?

Thanks a lot.

Jawa

* Statutory Disclaimer : These are merely my views.   *
* Jawahar M. Tembulkar, Computervision, R & D,        *
* 14 Crosby Drive, MS. 14-06, Bedford, MA 01730, USA. *