On Sun, 24 May 2009, J wrote: > > ...while the (non-disappearing) connections appear like: > > > > ./qpsmtpd-prefork [192.168.1.50 : testlaptop : 23:12:05 2009-05-23] > > It certainly appears that the processes (like above) get reused, but only > for the IP address that previously connected to it. I put the box on the > Internet for a while and I got several (obviously spammer) connections, > and they each left their own process behind after disconnecting. > > If I get time today, I'll drop the total connections and see what happens > when there are more connections than allowed - do the IP related processes > die off so a new one can start with the new IP? > > (I find it a bit disconcerting having all these processes hanging around.)
Okay, I think I understand what's happening, now... One IP can actually change a listening prefork process to a connection type process (as it appears in the process table), without reusing a previous one, if it still exists. Once a listening process is converted to a connection type process (even if it is inactive), it will hang around a while (100 connections?). If a different IP connects and uses a connection type process, it's information will then appear in the process table with that process - but it's still the same process. There's no more "Connection 1/50" in the log file. Okay. I can't count qpsmtpd processes, anymore, to determine how many current connections - netstat will do that. Okay. So, as soon as I either rollback DBI, or wait for a fix for SQL::Statement, I should be able to finish testing and roll prefork out. As I understand it, people that are using prefork can accept more concurrent connections than if they were using forkserver. J.
