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/
Hello All,
I'm setting up perdition for IMAP and Managesieve proxying with LDAP.
LDAP proxying is working fine, I'm getting my mailhost from there, but
for managesieve I keep getting: "perdition.managesieve[7871]: Exiting
on signal 11" and I'm wondering if it's a recurrence of this bug -
http://lists.vergenet.net/pipermail/perdition-users/2010-July/002332.html
. I'm using the Debian Squeeze with has the following packages in the
repos:
ii perdition 1.19~rc4-2
POP3 and IMAP4 Proxy server
ii perdition-ldap 1.19~rc4-2
Library to allow perdition to access LDAP based popmaps
Here is more of my log:
Mar 30 14:40:00 perdition-dev perdition.managesieve[7871]: Connect:
10.30.40.197:37245->10.30.40.163:4190
Mar 30 14:40:00 perdition-dev perdition.managesieve[7871]: SELF:
"\"IMPLEMENTATION\" \"perdition\"\r\n\"SIEVE\" \"comparator-i;octet
comparator-i;ascii-casemap fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex
imap4flags copy include variables body enotify environment mailbox
date\"\r\n\"SASL\" \"PLAIN\"\r\n\"NOTIFY\" \"mailto\"\r\n\"VERSION\"
\"1.19-rc4\"\r\nOK \"predition ready on perdition-dev.localnet.sys
0002b5e3\"\r\n"
Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: CLIENT:
"AUTHENTICATE \"PLAIN\"
\"AHRlc3RhY2NvdW50MDBAbG9jYWxuZXQuY29tAFRlY2g5OTk=\"\r\n"
Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]:
username_add_domain: username_add_domain 0 1
Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]:
username_add_domain: username_add_domain 0 4
///////////////////////////// THIS RESPONSE IS FROM THE CORRECT
MANAGESIEVE SERVER SO THE PROXY IS WORKING
/////////////////////////////
Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: REAL:
"\"IMPLEMENTATION\" \"dovecot\"\r\n\"SIEVE\" \"comparator-i;octet
comparator-i;ascii-casemap fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex
imap4flags copy include variables body enotify environment mailbox
date spamtest spamtestplus virustest\"\r\n\"SASL\" \"PLAIN
LOGIN\"\r\n\"STARTTLS\"\r\n\"NOTIFY\" \"mailto\"\r\n\"VERSION\"
\"1.0\"\r\nOK \"Dovecot ready.\"\r\n"
Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: Exiting on signal 11
So as you can see it exits after it connects to the correct
managesieve server. I can provide any more logging and answers if
someone has an idea where to look. Thanks, Jesse
I have a perdition server that is proxying for a Roundcube webmail as
well as all the various other email clients out there. On occasion
while a user is moving around their mail folders or opening emails
perdition will disconnect from the dovecot servers.
I get this error in the dovecot servers log:
dovecot: IMAP(username): Connection closed
That is the only thing I can see anywhere that indicates something
wrong. Most clients complain about a connection problem of some kind
then go on with life. Roundcube is a pain because when it happens it
kills the session and logs the user out. I updated to the latest
perdition and the issue hasn't gone away.
I am using Centos 5 which comes with dovecot 1.0.7 installed. I know
that is an old version but I don't really want to mess with it and make
it break if I update other parts of the server using the supported yum
repos. I also am not sure it has anything to do with the dovecot server
since if I point roundcube or another client directly at the dovecot
server without going though perdition it works with no issue. I would
like to find a solution with perdition since I have built a mail system
around it using 9 different mail hosts and one central point to check
your mail. I will look into updating the dovecot servers if that is
what it takes but I would like to avoid it if possible until they are
updated by the usual yum update.
I have looked for ip limits but I don't see any in that version of
dovecot. If I add the 'mail_max_userip_connections = 100' to the config
file dovecot will not even start so this version does not support it. I
moved the connection_limit in perdition up way past what the number of
connections that could possibly hit is and it didn't change the behavior.
One thing that I noticed that is a little different is when the client
is connecting directly it logs in using "A0002 AUTHENTICATE PLAIN
somelongstringofnumbersandletters". When it is going through perdition
it logs in like this:
flim08 LOGIN {7}
+ OK
username {8}
+ OK
password
flim08 OK Logged in.
I don't know if that makes any difference.
Thank you for any assistance.
Mark
