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/
Each server in the --bind_address option list passes through the function
user_server_port_strn_assign() (in perdition/server_port.c) which
separates the user, server and port components. This function does not
recognize IPv6 address literals as documented in RFC 3986 (i.e., IPv6
addresses enclosed in brackets.)
For example, address literal [2001:db8:1000:1::2] will be separated into
"server" [2001:db8:1000:1: and "port" 2] , which are syntactically
incorrect and will produce an error in getaddrinfo(). The enclosed patch
adds IPv6 literal handling.
(A workaround is to use a "naked" IPv6 address with the port
specification, e.g., 2001:db8:1000:1::2:110 , but this is a) ugly and b)
not standards-compliant.)
i.
When connecting to an LDAP server with the ldapi: URI scheme (using a UNIX
domain socket), the "host" portion of the URI contains the full path to
the socket special file. Forward slash characters in the path must be
URL-escaped to avoid confusion with the slashes that delimit the
components of the URI itself. The function perdition_ldap_uri() in
perdition/db/ldap/perditiondb_ldap.c doesn't handle ldapi:// URIs in any
special way, which makes it impossible to use such URIs for contacting the
LDAP server. The attached patch adds ldapi:// recognition and path
escaping to that function.
i.
Hi,
I'm happy to announce the release of perdition 1.19-rc4
Key changes:
* Fix parsing of NIS maps
* Fix a segmentation fault on start-up when the bind_address configuration
option is used.
* Fix handling of the debug and quiet options when specified a configuration
file
* Building without PAM libraries installed
* Documentation enhancements
A full change log is provided by the Mercurial repository
http://hg.vergenet.net/perdition/perdition/
Perdition 1.19-rc3 and the vanessa libraries that it depends on
are available from:
http://horms.net/linux/perdition/download/1.19-rc4/
Debian unstable packages have been uploaded to Debian.Org
and should be available in the Debian archive within 24 hours.
http://packages.debian.org/source/unstable/perdition
I will endeavour to get these new packages included in
testing and thus the up-coming Squeeze release.
Packages for various RPM based distributions are being built by the SUSE
build service and should be available shortly from
http://download.opensuse.org/repositories/home:/horms:/perdition/
Hi there,
I just found a bug in latest perdition version in the nis backend. The
syscal ypmatch is used with the wrong args. I just posted a bug to
debian with a patch to fix this issue.
Here it is so, if you aggree, please merge it and we can have nis
support back !
thanks,
Christophe
I am new to this list. We have been using perdition-1.17.1 for
the better part of two years ... thank you! We are running perdition
on Solaris 9 and 10. Some kind soul (can't remember who)
posted source for mkdtemp and I was able to compile using gcc
3.4.6 from www.sunfreeware.com.
We have been bitten by the Thunderbird 3.1 to perdition SSL/TLS bug.
I am trying to build and run perdition-1.19-rc3 ... so far
unsuccessfully.
When run, perdition gives a segmentation fault. Many thanks in
advance to
anyone who can shed any light on this!
I built and installed vanessa_logger-0.0.10, vanessa_adt-0.0.9, and
vanessa_socket-0.0.12.
perdition-1.19-rc3 compiled (with the addition of mkdtemp and the
following
patch):
diff perdition.c.orig perdition.c
582c582
< fromv = malloc(((nfrom * 2) + 1));
---
> fromv = malloc(sizeof(*fromv) * ((nfrom * 2) + 1));
But when I ran it, it got a segmentation fault.
gdb session showing segmentation fault:
gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10".
(gdb) file /local/staff/mail3/opt/sbin/perdition.imap4
Reading symbols from /local/staff/mail3/opt/sbin/perdition.imap4...done.
(gdb) b perdition.c:498
Breakpoint 1 at 0x8063e29: file perdition.c, line 498.
(gdb) r -C -d --inetd_mode \
-p 26993 -M /usr/local/lib/libperditiondb_ldap.so.
0 --ssl_ca_path /etc/mail/certs \
--ssl_cert_file /etc/mail/certs/mail3.crt --
ssl_key_file /etc/mail/certs/private/mail3.key \
--ssl_ca_file /etc/mail/certs/CA.crt --
ssl_no_cn_verify --log_facility -
Starting program: /local/staff/mail3/opt/sbin/perdition.imap4 -C -d --
inetd_mode -p 26993 -M /usr/local/lib/
libperditiondb_ldap.so.0 --ssl_ca_path /etc/mail/
certs --ssl_cert_file /etc/mail/certs/mail3.crt --
ssl_key_file /etc/mail/certs/private/mail3.key --
ssl_ca_file /etc/mail/certs/CA.crt --ssl_no_cn_verify --log_facility -
Using LDAP version: 3
Breakpoint 1, main (argc=19, argv=0x8047b40, envp=0x8047b90) at
perdition.c:498
498 if (log_options()) {
(gdb) s
log_options () at options.c:1473
1473 a = log_options_str();
(gdb) s
log_options_str () at options.c:1432
1432 a = calloc(4, sizeof(char *));
(gdb) n
1433 if (!a) {
(gdb) n
1438 a[0] = log_options_head_str();
(gdb) n
1439 if (!a[0])
(gdb) n
1441 a[1] = log_options_non_ssl_str();
(gdb) n
1442 if (!a[1])
(gdb) n
1445 a[2] = log_options_ssl_str();
(gdb) p a[0]
$1 = 0x808e390 "Starting perdition version=1.19-rc3 protocol=IMAP4"
(gdb) p a[1]
$2 = 0x808f398 "add_domain=\"\", authenticate_in=off,
authenticate_timeout=1800, bind_address=\"\",
client_server_specification=off, config_file=\"/usr/local/etc/
perdition/perdition.imap4.conf\", connection_limit=0, connec"...
(gdb) s
log_options_ssl_str () at options.c:1330
1330 char *ssl_mode_p = NULL;
(gdb) n
1331 char *out = NULL;
(gdb) n
1333 out = malloc(MAX_LINE_LENGTH);
(gdb) n
1334 if (!out) {
(gdb) n
1339 switch (opt.ssl_mode) {
(gdb) n
1347 ssl_mode_p=ssl_mode;
(gdb) n
1348 if (opt.ssl_mode & SSL_MODE_SSL_LISTEN &&
(gdb) n
1351 else if (opt.ssl_mode & SSL_MODE_TLS_LISTEN &&
(gdb) n
1355 if (opt.ssl_mode & SSL_MODE_SSL_LISTEN)
(gdb) n
1358 if (opt.ssl_mode &
SSL_MODE_SSL_OUTGOING)
(gdb) n
1359
LOG_OPTIONS_ADD_STR("ssl_outgoing", ssl_mode_p,
(gdb) n
1361 if (opt.ssl_mode & SSL_MODE_TLS_LISTEN)
(gdb) n
1362
LOG_OPTIONS_ADD_STR("tls_listen", ssl_mode_p,
(gdb) n
1364 if (opt.ssl_mode &
SSL_MODE_TLS_OUTGOING)
(gdb) n
1367 if (ssl_mode_p == ssl_mode)
(gdb) n
1372 if ((opt.ssl_mode & SSL_MODE_TLS_OUTGOING_FORCE) &&
(gdb) n
1377 if (opt.ssl_mode&SSL_MODE_TLS_OUTGOING_FORCE)
(gdb) n
1380 if (opt.ssl_mode&SSL_MODE_TLS_LISTEN_FORCE)
(gdb) n
1381
LOG_OPTIONS_ADD_STR("tls_listen_force", ssl_mode_p,
(gdb) n
1385 snprintf(out, MAX_LINE_LENGTH - 1,
(gdb) p out
$3 = 0x80903a0 ""
(gdb) p *out
$4 = 0 '\0'
(gdb) p ssl_mode
$5 = "ssl_outgoing,tls_listen,tls_listen_force"
(gdb) p opt_str(opt.ssl_ca_file)
$6 = 0x808c028 "/etc/mail/certs/CA.crt"
(gdb) p opt_str(opt.ssl_ca_path)
$7 = 0x808ba00 "/etc/mail/certs"
(gdb) p ((opt.ssl_ca_accept_self_signed)?"on":"off")
$8 = "off"
(gdb) p opt_str(opt.ssl_cert_file)
$9 = 0x808cd48 "/etc/mail/certs/mail3.crt"
(gdb) p ((opt.ssl_cert_accept_expired)?"on":"off")
$10 = "off"
(gdb) p ((opt.ssl_cert_accept_not_yet_valid)?"on":"off")
$11 = "off"
(gdb) p ((opt.ssl_cert_accept_self_signed)?"on":"off")
$12 = "off"
(gdb) p opt.ssl_cert_verify_depth
$13 = 9
(gdb) p opt_str(opt.ssl_key_file)
$14 = 0x808c9c0 "/etc/mail/certs/private/mail3.key"
(gdb) p opt_str(opt.ssl_listen_ciphers)
$15 = 0x80708a4 ""
(gdb) p opt_str(opt.ssl_outgoing_ciphers)
$16 = 0x80708a4 ""
(gdb) p ((opt.ssl_no_cert_verify)?"on":"off")
$17 = "off"
(gdb) p ((opt.ssl_no_client_cert_verify)?"on":"off")
$18 = "off"
(gdb) p ((opt.ssl_no_cn_verify)?"on":"off")
$19 = "on"
(gdb) p opt.ssl_passphrase_fd
$20 = 0
(gdb) p opt.ssl_passphrase_file
$21 = 0x0
(gdb) p opt.ssl_mask
$22 = 16918
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xfece58fc in strlen () from /lib/libc.so.1
Thanks!
Doug Shearer
Lamont-Doherty Earth Observatory of Columbia University
61 Route 9W
Palisades, NY 10964
