spamd SIGPIPEs

[Daniel Hartmeier <da...@benzedrine.cx>]

I'm connecting to spamd locally through TCP from a libmilter plugin. The
way libmilter gets the mail, it would be easiest for the plugin to not
have to tell spamd the size using Content-length: in advance.

Some trial and error showed that I can send a request like

  << SYMBOLS SPAMC/1.2\r\n
  << User: dhartmei\r\n
  << \r\n
  << From: test\r\n
  (...entire mail)

and then shutdown(SHUT_WR) the socket, triggering spamd to see the end
of input and returning the result, which I can still read. When spamd
has finished sending the result, it closes the connection, my read()
returns 0, and I close() the socket.

Everything appears to work fine, but I do see spamd logging SIGPIPEs
like

  spamd[pid]: SIGPIPE received - reopening log socket 

This occurs even with small test mails, when no timeouts are reached,
which leads me to suspect the scheme described above might not be
perfectly valid. :)

Is this signal caused by the client connection, or is the 'log socket'
something else completely? When I shutdown(SHUT_WR) the client
connection on the client, but keep reading until read() returns 0, how
can spamd get a SIGPIPE? As I understand it, that means it tried to
write to a socket which was closed?

Is there a better way to get a result from spamd without knowing the
size of the mail in advance? libmilter doesn't always give the size in
advance, and caching the entire mail just so I can tell spamd in advance
sounds expensive.

And, somewhat related, can spamd possibly start returning results before
it has read all input?

Daniel

Re: spamd SIGPIPEs

[Daniel Hartmeier <da...@benzedrine.cx>]

Turns out it was a simple bug on my side, I unintentionally opened two
connections to spamd each time, the second one was never closed until
the client terminated, and that's where the SIGPIPEs came from.

All is well now, and I assume the shutdown(SHUT_WR) instead of providing
Content-length: is proper way to do this. Sorry for the noise :)

Daniel