Hello,
we've been using perdition as a pop3/pop3s/imap/imaps proxy for about
four years now, first with Debian Sarge package and now under Etch.
And throughout this time I've seen pop3s (and from the looks of it
the same happens with imaps) processes stuck in connect, like this:
---
16836 ? S 5:31 0 120 32179 2204 0.0 perdition.pop3s
28070 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
7782 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
24468 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect
14180 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect
13503 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
---
They never die off, keep the connection open, there is no traffic and the
other end might be long gone. Last trace in the logs is always like this:
---
Feb 5 22:05:16 pp11 perdition[7782]: Connect: hi.mi.ts.u->203.216.5.113
---
It must be something related to the SSL'ness of these service, since I'm
not seeing this happening ever for imap/pop3. Alas a lot of people do use
TLS with those, so it's not a generic SSL issue. Maybe the master process
could kick a child handling connections in the head after "timeout"
seconds in connect state?
If more information is needed I can try to provide it, but note that with a
rate of roughly 35 pops per second I'm a bit weary to turn on
debugging. ^_-
This may or may not be related to another SSL related issue, which will
be for the sake of making searches in the archive more likely to find good
keywords in a separate mail.
Regards,
Christian
--
Christian Balzer Network/Systems Engineer NOC
chibi(a)gol.com Global OnLine Japan/Fusion Network Services
http://www.gol.com/
I'm using perdition quite successfully to
present a unified interface for users whose mail
resides on various back-end servers, using LDAP
routing.
But I foresee trouble ahead. A gmail backend, for example,
requires an imaps connection, regardless of how
the user reached the perdition proxy. gmail also
requires the full email address (foobar(a)gmail.com),
but other services just want the user id -- i.e.
the part before the '@'. There will probably be
cases where the user id on the backend is quite different
from the user id the user knows about and logs in with.
In short -- maybe it's a good idea to start thinking
about having more stuff be LDAP-driven than the
current three elements. Has there ever been a discussion
of some scriptable or extensible facility for
driving more back-end parameters from LDAP -- maybe
including even parameters that are normally driven
by command-line or config file parameters, on a per-
connection basis?
If this sounds like a good idea at all I'd be happy
to help with the work.
Best,
Michael J Smith
mjs(a)smithbowen.net