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: Connect: hi.mi.ts.u->18.104.22.168
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
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.
Christian Balzer Network/Systems Engineer NOC
chibi(a)gol.com Global OnLine Japan/Fusion Network Services
I'm happy to announce the release of perdition 1.19-rc5
Key changes since 1.19-rc4:
* ldap: fix segmentation fault in dbserver_get2()
* Manage-sieve: Fix handling of plain login which would segmentation fault in
* Manage-sieve: Fix handling of long authentication hashes
* Enhance --bind_address option parsing to handle IPv6 addresses
* Fix 8/4byte integer type miss-matches which may lead to undefined behaviour
A full change log is provided by the Mercurial repository
Perdition 1.19-rc5 and the vanessa libraries that it depends on
are available from:
Debian unstable packages have been uploaded to Debian.Org
and should be available in the Debian archive within 24 hours.
I use Perdition perdition-1.17.1_6 on FreeBSD 8.2 witch mysql option.
I want bridging IMAPS connection (993) to Perdition on IMAP (143) to real
server and POPS (995) connection on Perdition on POP(110) to real serveur.
All ports is setting to NULL in database
I activate SSL with:
I generate certificat thanks to man documentation
993 port is open but Perdition call with real server on port 993 instead
The bridging works fine if i set "port=143' in database but the POP proxy
Could you help me to find my mistake ?
thanks a lot
(i'm french and bad english...sorry)
Hi all together
my first post, so hopefully I do not ask something that has already been
asked several times :-)
I installed perdition on my server and it works very well for my local
dovecot. clients can connect and perdition connects to the local server.
So far perfect :-)
Now I thought that I could connect from perdition to other external
servers as well. So I set an entry in popmap for user(a)domain.tld to
point to server imap.domain.tld:995
But when I check the logfiles I can see that perdition cannot connect to
the external server. Although I can ping the server without problems.
One strange thing in the logs is that as protocol always IMAP4S is used,
even if port 995 would demand for POP3S.
How can I achieve that perdition connects via POP3S to a real server,
although the initial connection to perdition by client is based on
IMAP4S. I tried to setup the real server as well with port 993 in popmap
so port and protocol should match. but that did not work either.
Thanks for any idea on how to solve that
if you're still/again in Tokyo, how did you like the snow this morning? ^o^
Debian Squeeze, thus Perdition 1.19~rc4-2.
This version will log any and all session close activities to mail.warn
Aside from wasting disk space (not really an issue here) and making the
files pretty unreadable (I'd expect to find only a few lines of actual
problems if any happened in there) the logging to mail.err is
particular troublesome as this log file by default will be synced after
each entry. And I'm dealing with 20-50 sessions per second here.
Would be nice if this could be remedied.
Looking at older (1.17) logs I'd suggest that "Closing NULL session"
doesn't belong into mail.err, probably not even into mail.warn.
Christian Balzer Network/Systems Engineer
chibi(a)gol.com Global OnLine Japan/Fusion Communications