On Wed, Sep 12, 2001 at 08:17:56PM +0200, Eric Persson wrote:
> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
> exec /usr/local/bin/softlimit -m 2000000 \
> /usr/local/bin/tcpserver -v -R -l 0 -x /etc/tcp.smtp.cdb -c
> "$MAXSMTPD" \
> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp
> /var/qmail/bin/qmail-smtpd 2>&1
>
> The logs give no clue at all.
I have seen this behaviour before in case tcpserver hits its concurrency
limit.
You should find lines like
Sep 13 16:18:08 mail smtpd: 1000390688.148331 tcpserver: status: 34/80
indicating that tcpserver currently uses 34 out of max 80 slots.
If this goes to 80/80 (or $MAXSMTPD/$MAXSMTPD in your case) you will
experience the behaviour you had. tcpserver will still accept some
connections as backlog and start the qmail-smtpd for these as soon
as an existing connection finishes. Depending on the size of the incoming
messages and your bandwidth this may take quite some time.
Another problem could be with DNS. You may want try to add "-H" to the
tcpserver options. DNS problems could also lead to the problem that
there are more incoming connections than tcpserver is able to resolve.
This would also lead to a behaviour, where "qmail-smtpd works" after
a restart and stops after some time, as the tcpserver queue fills up.
Raising the value in /var/qmail/control/concurrencyincoming might solve
the situation.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
Stress is when you wake up screaming and you realize you haven't fallen
asleep yet.
