I also have some zombies of my servers running Debian Sarge 32bit with tls activated. Sorry that I am not able to provide more information at this time. Hopefully I can investigate this issue soon.
best, -harti On 01 Mar 08, Sam Clippinger wrote: > Sorry for the late reply -- I'm currently on the road so email is a low > priority this week. > > This is all very strange. If the debug version was running, I don't > understand why the debug symbols didn't show up in the stack trace you > sent. I also can't think of any other reasons why the OpenSSL library > would hang on a read() call; I can only think to blame the 64 bit > libraries but that's just a reflex, not an explanation. Without some > way to reproduce this behavior, I'm not sure what else I can do to fix it. > > Are there any other commonalities you can find with these stalled > processes? Do they seem to come from the same remote server(s)? Can > you tell if the remote server(s) are running the same mail server > software? Are the messages all small/large/junk/legitimate? Are the > recipients the same each time? Anything along these lines? > > To answer your question: yes, if spamdyke is compiled without TLS > support it will ignore the TLS options. > > -- Sam Clippinger > > Ken Schweigert wrote: > > On Mon, Feb 25, 2008 at 4:49 PM, Sam Clippinger <[EMAIL PROTECTED]> wrote: > >> Hmmm. Well, it looks like the spamdyke process you attached to isn't > >> running the binary with the debugging symbols; it probably started > >> before you copied the new binary into place, but it doesn't matter. > >> There's enough information to show what's going on. > > > > I did compile with the debug symbols. The resulting binary was 200K > > larger than the original so I knew there was something extra in there. > > Also it wouldn't let me overwrite the existing spamdyke binary > > because it was busy so I had to kill any processes that were running > > to put it in to place. > > > >> The process is stuck inside the OpenSSL library, trying to negotiate an > >> initial TLS connection with the remote host (gdb shows > >> ssl23_get_client_hello() from /lib64/libssl.so.4). The negotiation is > >> attempting to read data from the network (__read_nocancel() from > >> /lib64/tls/libc.so.6) but there's no data available, so it's blocked > >> forever, waiting on data that (apparently) never comes. If you enable > >> full logging and examine the log from one of these sleeping processes, > >> I'm sure you'd see a "STARTTLS" command followed by a "Proceed" response > >> and nothing else. > >> > >> Obviously, this isn't supposed to happen -- the OpenSSL library has a > >> timeout feature that defaults to 5 minutes. Since that's not working, I > >> suspect there's something else going on. First, I'd check to make sure > >> you've got the latest version of the OpenSSL library installed and the > >> installed header files came from that version. In other words, check > >> the version numbers on your openssl and openssl-dev RPM packages. > > > > I use Redhat's up2date utility and all packages are up to date. I've > > had times where features in the newest source weren't in the RPMs and > > had to compile openssl from source. Something I'm not afraid of doing > > and may consider doing in the future. > > > >> Next, I notice your mail server is running a 64 bit RedHat release. Did > >> you compile spamdyke on this machine? I recall once answering a report > >> similar to yours where the spamdyke binary had been compiled on a 32 bit > >> system and copied to the 64 bit system. If you're compiling elsewhere, > >> both machines need to be 64 bit with the same version of the OpenSSL > >> library. > > > > Yes, compiled on the server that it is running on. Not sure if there > > are any specific 64-bit flags that need to be set in 'configure' but I > > imagine they would have been picked up auto-magically. > > > >> Lastly, are you using spamdyke for SMTPS (port 465)? It doesn't work > >> well with SMTPS connections at the moment unless you run it from > >> something like stunnel and remove the "tls-certificate-file" option from > >> the configuration file. > > > > Not running on SMTPS. My users send through authenticated SMTP on > > 587. I have spamdyke protecting incoming smtp 25 but not on the 587 > > instance. > > > >> My only other suggestion would be to compile spamdyke without TLS > >> support (or remove the "tls-certificate-file" option) so that spamdyke > >> doesn't attempt to accept the TLS connection itself. That would mean > >> spamdyke wouldn't fully filter TLS connections but at least these > >> sleeping processes would go away. > > > > I just recompiled spamdyke with './configure --disable-tls' . Is it > > safe to assume that since it's compiled this way that any > > configuration options about SSL will be ignored? > > > > Thanks for all your help! > > -ken > > > > > >> I hope that helps! > >> > >> > >> -- Sam Clippinger > >> > >> Ken Schweigert wrote: > >> > >> > >>> I've recompiled with debug symbols and have attached the output of > >> > what 'gdb' has. I have to admit that I don't really understand what > >> > is exactly is represented, but it doesn't look like a lot. > >> > > >> > ################################################ > >> > [EMAIL PROTECTED] ~]# gdb /usr/local/bin/spamdyke > >> > GNU gdb Red Hat Linux (6.3.0.0-1.153.el4_6.2rh) > >> > Copyright 2004 Free Software Foundation, Inc. > >> > GDB is free software, covered by the GNU General Public License, and > >> you are > >> > welcome to change it and/or distribute copies of it under certain > >> conditions. > >> > Type "show copying" to see the conditions. > >> > There is absolutely no warranty for GDB. Type "show warranty" for > >> details. > >> > This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging > >> > symbols found) > >> > Using host libthread_db library "/lib64/tls/libthread_db.so.1". > >> > > >> > (gdb) attach 4113 > >> > Attaching to program: /usr/local/bin/spamdyke, process 4113 > >> > Reading symbols from /lib64/libnsl.so.1...(no debugging symbols > >> found)...done. > >> > Loaded symbols for /lib64/libnsl.so.1 > >> > Reading symbols from /lib64/libresolv.so.2...(no debugging symbols > >> > found)...done. > >> > Loaded symbols for /lib64/libresolv.so.2 > >> > Reading symbols from /lib64/libcrypto.so.4...(no debugging symbols > >> > found)...done. > >> > Loaded symbols for /lib64/libcrypto.so.4 > >> > Reading symbols from /lib64/libssl.so.4...(no debugging symbols > >> found)...done. > >> > Loaded symbols for /lib64/libssl.so.4 > >> > Reading symbols from /lib64/tls/libc.so.6... > >> > (no debugging symbols found)...done. > >> > Loaded symbols for /lib64/tls/libc.so.6 > >> > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...(no debugging > >> > symbols found)...done. > >> > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > >> > Reading symbols from /usr/lib64/libkrb5.so.3...(no debugging symbols > >> > found)...done. > >> > Loaded symbols for /usr/lib64/libkrb5.so.3 > >> > Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols > >> > found)...done. > >> > Loaded symbols for /lib64/libcom_err.so.2 > >> > Reading symbols from /usr/lib64/libk5crypto.so.3... > >> > (no debugging symbols found)...done. > >> > Loaded symbols for /usr/lib64/libk5crypto.so.3 > >> > Reading symbols from /lib64/libdl.so.2...(no debugging symbols > >> found)...done. > >> > Loaded symbols for /lib64/libdl.so.2 > >> > Reading symbols from /usr/lib64/libz.so.1...(no debugging symbols > >> found)...done. > >> > Loaded symbols for /usr/lib64/libz.so.1 > >> > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging > >> > symbols found)...done. > >> > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > >> > Reading symbols from /lib64/libnss_files.so.2... > >> > (no debugging symbols found)...done. > >> > Loaded symbols for /lib64/libnss_files.so.2 > >> > 0x00000035647b9e82 in __read_nocancel () from /lib64/tls/libc.so.6 > >> > (gdb) > >> > (gdb) Quit > >> > (gdb) where > >> > #0 0x00000035647b9e82 in __read_nocancel () from /lib64/tls/libc.so.6 > >> > #1 0x0000003fba190fb1 in BIO_sock_should_retry () from > >> /lib64/libcrypto.so.4 > >> > #2 0x0000003fba18f1d3 in BIO_read () from /lib64/libcrypto.so.4 > >> > #3 0x0000003fba41e9cf in ssl23_read_bytes () from /lib64/libssl.so.4 > >> > #4 0x0000003fba41d7fa in ssl23_get_client_hello () from > >> /lib64/libssl.so.4 > >> > #5 0x0000003fba41dcad in ssl23_accept () from /lib64/libssl.so.4 > >> > #6 0x0000000000415947 in ?? () > >> > #7 0x0000000000403b64 in ?? () > >> > #8 0x000000000040649b in ?? () > >> > #9 0x0000000000408ece in ?? () > >> > #10 0x000000000040ea67 in ?? () > >> > #11 0x000000356471c3fb in __libc_start_main () from /lib64/tls/libc.so.6 > >> > #12 0x000000000040290a in ?? () > >> > #13 0x0000007fbffffc78 in ?? () > >> > #14 0x000000000000001c in ?? () > >> > #15 0x0000000000000006 in ?? () > >> > #16 0x0000007fbffffe23 in ?? () > >> > #17 0x0000007fbffffe3b in ?? () > >> > #18 0x0000007fbffffe3e in ?? () > >> > #19 0x0000007fbffffe51 in ?? () > >> > #20 0x0000007fbffffe6c in ?? () > >> > #21 0x0000007fbffffe86 in ?? () > >> > #22 0x0000000000000000 in ?? () > >> > (gdb) > >> > ################################################ > >> > > >> > Here is the contents of my spamdyke.conf file: > >> > > >> > ################################################ > >> > log-level=2 > >> > log-target=0 > >> > local-domains-file=/var/qmail/control/rcpthosts > >> > max-recipients=25 > >> > # connection-timeout-secs=0 is disabling the feature > >> > connection-timeout-secs=0 > >> > idle-timeout-secs=180 > >> > no-graylist-dir=/home/vpopmail/graylist > >> > #graylist-dir=/home/vpopmail/graylist > >> > #graylist-min-secs=120 > >> > #graylist-max-secs=1814400 > >> > #never-graylist-ip-file=/home/vpopmail/never_graylist_these_ips > >> > #policy-url=http://my.policy.explanation.url/ > >> > sender-blacklist-file=/home/vpopmail/blacklist_senders > >> > recipient-blacklist-file=/home/vpopmail/blacklist_recipients > >> > #ip-in-rdns-keyword-file=/home/vpopmail/blacklist_keywords > >> > ip-blacklist-file=/home/vpopmail/blacklist_ip > >> > reject-empty-rdns > >> > #reject-unresolvable-rdns > >> > rdns-whitelist-file=/home/vpopmail/whitelist_rdns > >> > ip-whitelist-file=/home/vpopmail/whitelist_ip > >> > greeting-delay-secs=5 > >> > check-dns-whitelist=whitelist.mydomain.tld > >> > check-dnsrbl=safe.dnsbl.sorbs.net > >> > check-dnsrbl=combined.njabl.org > >> > check-dnsrbl=sbl-xbl.spamhaus.org > >> > check-dnsrbl=bogons.cymru.com > >> > reject-missing-sender-mx > >> > tls-certificate-file=/var/qmail/control/servercert.pem > >> > ################################################ > >> > > >> > > >> > The two error messages that I see in my smtpd logs are: > >> > > >> > @4000000047be7b362877c784 ERROR: unable to construct data packet: > >> > Message too long > >> > @4000000047be8e4d1cdf327c ERROR: unable to start SSL/TLS connection: > >> > The operation failed due to an I/O error, Unexpected EOF found > >> > > >> > The first one appears every 8-12 hours, but the second one appears > >> > every hour or so. I'm not sure how to correlate these errors with > >> > when the actual process went in to zombie mode. > >> > > >> > Let me know if there is any thing else you would like me to try or any > >> > other information I can provide. > >> > -ken > >> > >> > >> _______________________________________________ > >> spamdyke-users mailing list > >> [email protected] > >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > >> > > > > > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
