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/
Since I'm on the subject of logging...
I notice that even if I am coming in on port 993, the port field that is
logged is the port of the outgoing connection:
Apr 4 11:19:24 auk perdition[19421]: Auth: 0.0.0.0->0.0.0.0 ---- server="0.0.0.0" port="143" status="ok"
In this case, my incoming imap connection was an imaps (993) connection
to perdition, it then looked up my user and found the server to connect
to, and then made the connection to that server over port 143. I
expected it to connect to the remote server over 143, but I was
expecting to get a log entry from perdition that the port it received
the connection on is port 993.
Is there a way to get a log entry that indicates the incoming port
number, as well as the outgoing one?
Thanks!
micah
--
"It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti
Hi!
We are using perdition 1.17.1 on Centos 5.3 x64.
I tried to use the CentOS repo for updating to 1.18 but that version
dies immediately after a imap4 connect with "Exit 11" -
as we are using ldap as database I thing that is related to that patch
http://hg.vergenet.net/perdition/perdition/rev/28264fe9e31b
so I tried to compile perdition 1.18 manually.
That fails with:
-DHAVE_CONFIG_H -I. -I.. -DPERDITION_LIBDIR=\"/opt/perdition180/lib\"
-DPERDITION_SYSCONFDIR=\"/opt/perdition180/etc/perdition\"
-DPERDITION_LOCALSTATEDIR=\"/opt/perdition180/var\" -I/usr/include
-g -O2 -MT perdition.o -MD -MP -MF .deps/perdition.Tpo -c -o perdition.o
perdition.c
perdition.c: In function »main«:
perdition.c:547: Warning: Zuweisung erzeugt Zeiger von Ganzzahl ohne
Typkonvertierung
perdition.c:712: Fehler: expected expression before »else«
perdition.c:950: Fehler: expected expression before »else«
perdition.c:998: Fehler: expected expression before »else«
make[3]: *** [perdition.o] Fehler 1
make[3]: Leaving directory `/root/perdition-1.18/perdition'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/root/perdition-1.18/perdition'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/root/perdition-1.18'
make: *** [all] Fehler 2
Can somebody give me a hint please?
regards martin
Dear all perdition users and experts,
I used to have perdition-1.17 work for my mail servers to query for LDAP
for mailHost for POP3 and IMAP proxy and normally I will just add a flag
in /etc/sysconfig/perdition for POP3 and IMAP and everything will just
working fine. Today, I've just setup another mail server (to load
balance the mail scanning process and POP/IMAP login) and install with
perdition-1.18 (tried also with perdition-1.18rc1), the configuration is
the same with my old perdition but I've problem to start the service the
error message below. If I remove the (mail=%45s), the service will just
start perfect but off course I can't login because ldap will not return
anything without the filter. Is there any issue with the new perdition
for LDAP query? Looking forward your kind assistance in this matter.
Starting perdition services (POP3): /bin/bash: -c: line 0: syntax error
near unexpected token `('
/bin/bash: -c: line 0: `ulimit -S -c 0 >/dev/null 2>&1 ;
/usr/sbin/perdition.pop3 -m
ldap://ldap.abc.com:389/dc=.?uid,mailHost?sub?(mail=%45s)?!BINDNAME=cn=xxx%2cdc=.,X-BINDPW=yyy'
Regards
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
I've been trying to determine which users are using what ports, in an
effort to transition people away from non-encrypted
connections. However, i'm having difficulty because the perdition logs
don't seem to log the username in any consistent way that I can
determine.
In many cases I see logs like this:
Apr 4 06:26:43 auk perdition[23849]: Auth: 0.0.0.0->0.0.0.0 ---- server="0.0.0.0" port="143" status="ok"
with no username logged, but in other cases I do see the username
logged, although in an odd way:
Apr 4 06:27:36 auk perdition[23147]: Auth: 0.0.0.0->0.0.0.0 ----micah(a)riseup.net" server="0.0.0.0" port="143" status="ok"
What can I do to get the username logged properly?
On a side note, I was expecting it to show up as
'username=micah(a)riseup.net' but it seems to be formatted funny.
thanks for your work on perdition,
micah
--
"It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti