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.
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. 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. 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. 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 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
