Robin Bowes wrote:
Hi,

I'm building a new qmail/qpsmntpd installation on an x86_64 platform.

All seemed to be going well until I tried connecting to qpsmtpd on port
2525.

It takes slightly longer than 30 secs to respond with the smtp greeting.

Here's my run file:

#!/bin/sh
QMAILDUID=`id -u qpsmtpd`
NOFILESGID=`id -g qpsmtpd`
PORT=2525
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
MAXCLIENTS=15
QPSMTPD_DIR=/var/qpsmtpd/0.3x

cd $QPSMTPD_DIR
HOST=`head -1 config/IP`

#exec /usr/local/bin/softlimit -m 50000000 \
exec        /usr/local/bin/tcpserver -v -R -p \
        -x /etc/tcp.smtp.cdb \
        -c $MAXSMTPD \
        -u $QMAILDUID \
        -g $NOFILESGID \
        $HOST $PORT \
        ./qpsmtpd 2>&1
#        /usr/bin/speedy -Tw -- -M$MAXCLIENTS ./qpsmtpd 2>&1


As you can see, I've removed softlimit for now and disabled speedycgi
until I get to the bottom of the issue.

I'm launching the run file with strace from the command line. Here's the
last few lines of the output when I start it up:

setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [-10225977829359615], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(2525),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(2525),
sin_addr=inet_addr("0.0.0.0")}, [18436518095880192016]) = 0
listen(3, 20)                           = 0
fcntl(3, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR)               = 0
setgroups(1, [509])                     = 0
setgid(509)                             = 0
setuid(509)                             = 0
close(0)                                = 0
close(1)                                = 0
write(2, "tcpserver: status: 0/20\n", 24tcpserver: status: 0/20
) = 24
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
accept(3,


When I telnet to port 2525, here's the output:

          {sa_family=AF_INET, sin_port=htons(42921),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
write(2, "tcpserver: status: 1/20\n", 24tcpserver: status: 1/20
) = 24
clone(tcpserver: pid 10541 from 127.0.0.1
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x2aaaaaab6430) = 10541
close(0)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
accept(3,

Then, about 30 secs later:

          tcpserver: ok 10541 localhost:127.0.0.1:2525 :127.0.0.1::42921
10541 Loaded logging/adaptive.rb acceptlevel 4 acceptprefix ++
rejectlevel 4 rejectprefix -- maxlevel 6
10541 loading plugins from ./plugins
10541 Connection from [127.0.0.1] [127.0.0.1]


Has anyone got any idea why there's such a delay between the initial
connection and the greeting response?

R.
Is tcpserver not loading qpsmtpd for those 30 seconds?
Can't be check_earlytalker's delay then.

Check your tcpserver dns-related options "-v -R -p". I think
that "-p" could be requiring a reverse ip lookup for ptr
record "localhost". A lot of mail servers have forward but
not reverse dns so I never use "-p". I use "-P -R -H" and
let qpsmtpd do its own dns checks. That could be it. And
your dns server log might help.

http://cr.yp.to/ucspi-tcp/tcpserver.html

Data-gathering options:

   * -h: (Default.) Look up the remote host name in DNS to set the
     environment variable $TCPREMOTEHOST.
   * -H: Do not look up the remote host name in DNS; remove the
     environment variable $TCPREMOTEHOST. To avoid loops, you /must/
     use this option for servers on TCP port 53.
   * -p: Paranoid. After looking up the remote host name in DNS, look
     up the IP addresses in DNS for that host name, and remove the
     environment variable $TCPREMOTEHOST if none of the addresses match
     the client's IP address.
   * -P: (Default.) Not paranoid.
   * -l /localname/: Do not look up the local host name in DNS; use
     /localname/ for the environment variable $TCPLOCALHOST. A common
     choice for /localname/ is 0. To avoid loops, you /must/ use this
     option for servers on TCP port 53.
   * -r: (Default.) Attempt to obtain $TCPREMOTEINFO from the remote host.
   * -R: Do not attempt to obtain $TCPREMOTEINFO from the remote host.
     To avoid loops, you /must/ use this option for servers on TCP
     ports 53 and 113.
   * -t /n/: Give up on the $TCPREMOTEINFO connection attempt after /n/
     seconds. Default: 26.

64-bit for real gig-e and gigbps on pci bus, too. Cool.

-Bob

Reply via email to