Perdition-users February 2012

perdition-users@vergenet.net

5 participants
5 discussions

Zombie pop3s (and imaps?) processes in connect state

by Christian Balzer

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/

11 years, 4 months

Problem with external Real Server

by tobi

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 Cheers tobi

12 years, 1 month

Perdition being far too chatty in the mail warn and error logs

by Christian Balzer

Hello Simon, 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 and mail.err. 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. Regards, Christian -- Christian Balzer Network/Systems Engineer chibi(a)gol.com Global OnLine Japan/Fusion Communications http://www.gol.com/

12 years, 1 month

Fatal error accepting child connection

by N V

Hi, last night i get the following error in the log perdition.imaps[2686]: Fatal error accepting child connection. Exiting. I checked Google but didn't find anything Does anybody see the same error? My setup: Debian 6.0.3 i386 Perdition 1.19-rc4 Sorry about my English... Thanks in advance! Nix

12 years, 1 month

Errors in perdition IMAP auth to courier-imap

by Todd Taylor

Hello, We have deployed Perdition 1.19rc4 to proxy user requests during a migration with popmap via LDAP. While POP works fine, we are seeing authentication failures through Perdition to the Courier IMAP, as shown below. I see there was a similar issue reported in build 1.18, in early 2011, but it was thought to be fixed since then. That post is at: http://lists.vergenet.net/pipermail/perdition-users/2011-January/002468.html Am I missing an IMAP configuration setting or is this still a bug? Any help you can offer is much appreciated. Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: CLIENT: ". login hemigtest5(a)unix.local<mailto:hemigtest5@unix.local> password\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: username_add_domain: username_add_domain 0 1 Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: do_getserver: dbserver_get returned empty string Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: username_add_domain: username_add_domain 0 4 Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: REAL: "* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA ACL ACL2=UNION XIMAPPROXY] Courier-IMAP ready. Copyright 1998-2010 Double Precision, Inc. See COPYING for distribution information.\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: SELF: "flim0a CAPABILITY\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: REAL: "* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA ACL ACL2=UNION XIMAPPROXY\r\nflim0a OK Completed\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: SELF: "flim0b LOGIN {21}\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: REAL: "+ go ahead\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: SELF: "hemigtest5(a)unix.local<mailto:hemigtest5@unix.local> {8}\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: REAL: "flim0b NO LOGIN failed\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: imap4_out_response: invalid tag from server 1 Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: imap4_out_authenticate: imap4_out_response name Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: SELF: "password\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: REAL: "password BAD Null command\r\n" Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: imap4_out_response: invalid tag from server 1 Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: imap4_out_authenticate: imap4_out_response passwd Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: main: protocol->out_authenticate -1 Feb 9 14:53:44 dp-perdition-01 perdition.imap4[5904]: Fatal error authenticating user. Exiting child. Thanks, Todd

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users February 2012