Jürgen Knelangen wrote:
Of course $maxprocs is very soon reached and they cannot connect.
I set $maxprocs temporary very high so they can login. My process list gathers
hundreds of lines like this (ps axu):
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 16101 0.0 0.0 1616 412 ? S 16:40 0:00
/usr/lib/courier/courier/courierpop3login
/usr/lib/courier/courier/courierpop3d Maildir
Logfile looks like this:
Dec 4 16:22:23 www courierpop3login: Connection, ip=[::ffff:x.x.x.x]
Dec 4 16:22:23 www courierpop3login: Connection, ip=[::ffff:x.x.x.x]
Dec 4 16:22:23 www courierpop3login: LOGIN, user=web2p2, ip=[::ffff:x.x.x.x]
Dec 4 16:22:23 www courierpop3login: LOGOUT, user=web2p2,
ip=[::ffff:x.x.x.x], top=0, retr=0, rcvd=12, sent=39, time=0
There is a LOGOUT but the process does not get killed.
That doesn't make any sense at all. The LOGOUT message is written by
the loop() function in pop3dserver.c, which immediately returns to the
main function. The main function then return(0)s. Furthermore, when
users LOGIN, the command that you'll see in the process list changes from:
/usr/lib/courier/libexec/courier/courierpop3login \
/usr/lib/courier/libexec/courier/courierpop3d Maildir
to:
/usr/lib/courier/libexec/courier/courierpop3d Maildir
First, use 'ps ax' and get a list of all of the PIDs of courierpop3login
processes running on your system. Then use 'netstat -tnp' to determine
what remote host is connected to those PIDs.
As Sam said, some bungled firewall could be dropping connections without
closing them on your pop3 server's side, but it could also be that some
bungled software is connecting to your pop3 server and just leaving the
connection open. Either way, the connections that LOGOUT are not the
ones that are stacking up.
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] pop3 connections ...
