SA Bugzilla – Bug 3991
RFE: spamd should allow listen on both UNIX and TCP sockets
Last modified: 2007-04-10 05:38:42 UTC
at some stage, we should fix spamd to support listening on multiple listen sockets -- namely a TCP/IP socket as default, *and* a UNIX domain socket at the same time. this would greatly ease deployment of UNIX-domain spamd, which is faster, but currently requires that all users of spamc change their commandlines to use.
aiming (optimistically) at 3.1.0
pessimising -> 3.2.0
This was a suggested idea for the Google Summer of Code 2006; I'm adding it to the bugzilla for future use, and in case anyone feels like implementing it. Subject ID: spamassassin-spamd-unix-and-tcp Keywords: spamd, unix-domain, sockets, networking, perl Description: http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3991 : currently spamd supports either UNIX-domain or TCP/IP sockets for incoming scan requests. It should support both simultaneously, in the one set of daemon processes. Possible Mentors: Justin Mason (jm at jmason.org)
actually, not that hard after all; now implemented and in trunk: : jm 241...; svn commit -m "bug 3991: spamd can now listen on UNIX domain, TCP, and SSL sockets simultaneously. Command-line semantics extended slightly, although fully backwards compatibly; add the --ssl-port switch to allow TCP and SSL listening at the same time" Sending MANIFEST Sending lib/Mail/SpamAssassin/SpamdForkScaling.pm Sending spamd/spamd.raw Adding t/spamd_unix_and_tcp.t Transmitting file data .... Committed revision 470934.
This is breaking t/spamd_ssl.t when SpamAssassin is built with ENABLE_SSL=yes Running spamd with ssl breaks in the same way. I wasn't paying attention to this until now, so it may just be that command line options are not backwards compatible like the comments in the patch say they are supposed to be, but I'm reopening this bug until this is resolved. The debugging output and error message from t/spamd_ssl.t and from running spamd with --ssl looks like spamd is trying to open two sockets on the same port: t/spamd_ssl....spamd start failed: log: [10577] dbg: logger: adding facilities: all [10577] dbg: logger: logging level is DBG [10577] dbg: spamd: creating SSL socket: [10577] dbg: spamd: Listen: 128 [10577] dbg: spamd: LocalAddr: 127.0.0.1 [10577] dbg: spamd: LocalPort: 43339 [10577] dbg: spamd: Proto: 6 [10577] dbg: spamd: ReuseAddr: 1 [10577] dbg: spamd: SSL_cert_file: data/etc/testhost.cert [10577] dbg: spamd: SSL_key_file: data/etc/testhost.key [10577] dbg: spamd: SSL_verify_mode: 0 [10577] dbg: spamd: Type: 1 [10577] dbg: spamd: creating INET socket: [10577] dbg: spamd: Listen: 128 [10577] dbg: spamd: LocalAddr: 127.0.0.1 [10577] dbg: spamd: LocalPort: 43339 [10577] dbg: spamd: Proto: 6 [10577] dbg: spamd: ReuseAddr: 1 [10577] dbg: spamd: Type: 1 [10577] error: spamd: could not create INET socket on 127.0.0.1:43339: Address already in use spamd: could not create INET socket on 127.0.0.1:43339: Address already in use
What t/spamd_ssl.t and the way I run spamd have in common is that they use --ssl and --port arguments to spamd. My guess from the comments in the patch is that specifying --ssl and --port without specifying --ssl-port in interpreted to mean open both plain and ssl sockets and to use --port for the value of --ssl-port. For backwards compatibility, --ssl --port=n should mean that only an ssl socket is opened. I think a good way of handling it would be to test if the port and ssl-port are equal once they are decided on, and if they are not open a non-ssl socket. If the command line explicitly says --port=n --ssl-port=n that could trigger a warning, but I don't think it has to be an error.
That does seem to be the problem. The sanity check of the options in spamd first checks if --ssl is specified without --ssl-port and in that case disables listening on an inet socket. Then it checks other options including --port to decide to enable listening on an inet socket, undoing the effect of the previous test. I've checked in a trivial fix that moves the check for --ssl-port not specified into the test for whether there will be listening for ssl, as that is the right place to decide that listening on an ssl socket precludes using --port for an inet socket. Committed revision 473556.
note -- this shouldn't be on the Google SOC list anymore, as it's been implemented!