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/
Hi Horms!
Modifications on *spec.in ( for vanessa_logger vanessa_adt
vanessa_socket perdition) are need for "rpmbuild -ta <name>.tar.gz" on
Fedora >7 ? systems (rpm ver 4.4.xx)
-> Copyright: GNU Lesser General Public Licence
-< License: GNU (or wherever)
Thanks for your magnific work ! :-)
The original IPv6 patches I submitted earlier didn't build on Linux
systems. Attached are updated IPv6 patches which have been tested
successfully in inetd mode on CentOS 5. However, in daemon mode under
CentOS, sometimes the spawned process will segfault. I'm still trying to
determine whether this is due to a problem with the patch itself or the
way I've built the RPM. Both daemon mode and inetd mode under FreeBSD
seems to work reliably though so I suspect this problem is something
peculiar to Linux which I've overlooked. In any case, I'm putting these
updated patches out in the hope of getting additional data back from
anyone running perdition in daemon mode on Linux systems.
Antonio Querubin
whois: AQ7-ARIN
Hello,
I've a problem with perdition setup.
I've set up it on a standard CentOS5 with the src-rpms from Simon Matter. (http://www.invoca.ch/pub/packages/perdition/)
My Config:
/etc/perdition/perdition.conf:
M /usr/lib/libperditiondb_ldap.so.0
m ldap://my-openldap.server/dc=.?uid,mailHost?sub?(uid=%s)
t 120
U
/etc/sysconfig/perdition:
POP3=yes
POP3_FLAGS="--debug"
IMAP4=yes
IMAP4_FLAGS=
Then I start the perdition and make a connect on port 110.
After the POP3 PASS Command, I get "-ERR Could not determine server"
In the maillog i see the following:
Jun 19 14:56:26 lbmfim05 perdition[11320]: version=1.17.1, add_domain="", authenticate_in=off, bind_address="", capability="UIDL USER", client_server_specification=off, config_file="/etc/perdition/perdition.conf", connection_limit=0, connection_logging=off, connect_relog=300, debug=on, domain_delimiter="@", explicit_domain="", group="nobody", inetd_mode=off, listen_port="110", log_facility="mail", login_disabled=off, lower_case="", map_library="/usr/lib/libperditiondb_ldap.so.0", map_library_opt="ldap://my-openldap.server/dc=.?uid,mailHost?sub?(uid=%s)", no_bind_banner=off, no_daemon=off, no_lookup=off, nodename="lbmfim05", ok_line="You are so in", outgoing_port="110", outgoing_server="", pid_file="/var/run/perdition/perdition.pop3", protocol="POP3", server_resp_line=off, strip_domain="", timeout=120, username="nobody", username_from_database=off, query_key="", quiet=off, ssl_mode="", ssl_ca_file="", ssl_ca_path="/etc/perdition/perdition.ca/", ssl_ca_accept_self_signed="off", ssl_cert_file="/etc/perd
Jun 19 14:56:26 lbmfim05 perdition[11320]: vanessa_socket_daemon_setid: uid=99 euid=99 gid=99 egid=99
Jun 19 14:56:26 lbmfim05 perdition[11324]: Error loading certificate chain file "/etc/perdition/perdition.crt.pem"
Jun 19 14:56:26 lbmfim05 perdition[11324]: Fatal error establishing SSL context for listening
Jun 19 14:56:26 lbmfim05 perdition[11328]: version=1.17.1, add_domain="", authenticate_in=off, bind_address="", capability="IMAP4 IMAP4REV1", client_server_specification=off, config_file="/etc/perdition/perdition.conf", connection_limit=0, connection_logging=off, connect_relog=300, debug=off, domain_delimiter="@", explicit_domain="", group="nobody", inetd_mode=off, listen_port="143", log_facility="mail", login_disabled=off, lower_case="", map_library="/usr/lib/libperditiondb_ldap.so.0", map_library_opt="ldap://my-openldap.server/dc=.?uid,mailHost?sub?(uid=%s)", no_bind_banner=off, no_daemon=off, no_lookup=off, nodename="lbmfim05", ok_line="You are so in", outgoing_port="143", outgoing_server="", pid_file="/var/run/perdition/perdition.imap4", protocol="IMAP4", server_resp_line=off, strip_domain="", timeout=120, username="nobody", username_from_database=off, query_key="", quiet=off, ssl_mode="", ssl_ca_file="", ssl_ca_path="/etc/perdition/perdition.ca/", ssl_ca_accept_self_signed="off", ssl_cert_file="/
Jun 19 14:56:26 lbmfim05 perdition[11332]: Error loading certificate chain file "/etc/perdition/perdition.crt.pem"
Jun 19 14:56:26 lbmfim05 perdition[11332]: Fatal error establishing SSL context for listening
Jun 19 14:56:29 lbmfim05 perdition[11335]: Connect: 127.0.0.1->127.0.0.1
Jun 19 14:56:37 lbmfim05 perdition[11335]: username_add_domain: username_add_domain 0 1 0xa04b5d4
Jun 19 14:56:37 lbmfim05 perdition[11335]: dbserver_get: ldap_bind_s: Protocol error
Jun 19 14:56:37 lbmfim05 perdition[11335]: getserver: do_dbserver_get
Jun 19 14:56:40 lbmfim05 perdition[11335]: Auth: 127.0.0.1->127.0.0.1 user="puri_at__test" server="(null)" port="110" status="failed: Could not determine server"
Jun 19 14:56:41 lbmfim05 perdition[11335]: Closing NULL session: 127.0.0.1->127.0.0.1 username=(null)
What did I wrong, that I get the "dbserver_get: ldap_bind_s: Protocol error"-Error???
--
Klemens