[rabbitmq-discuss] Librabbitmq

David Wragg david at rabbitmq.com
Thu May 27 15:47:26 BST 2010

Hi Pieter,

Pieter de Zwart <pdezwart at rubiconproject.com> writes:
> I am having some trouble with the librabbitmq library, and I am hoping you
> can help me out. We have managed to created a situation whereby a connection
> gets closed down, but the PHP client does not know about it yet. As a
> result, when it tries to clean itself up with amqp_channel_close(), a
> SIGPIPE is thrown and PHP gets all kinds of pissed off.
> I was wondering if you could help me either:
> 1. catch SIGPIPE in the PHP C client somehow. (I am a n00b.)
> 2. pass some sort of flag to the connection to ignore SIGPIPE and return
> false instead. In case you are as clueless as I am (I am sure you are not,
> but just in case) I found this:
> setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

I haven't heard of SO_NOSIGPIPE before - it seems to be only available
on OS X.

There are a couple of other options:

3. If the process sets the handler for SIGPIPE to SIG_IGN, then SIGPIPE
  will not be raised, and the offending write call will fail with EPIPE.
  A lot of UNIX processes do this, I believe; SIGPIPE is often more of a
  nuisance than a feature.  librabbitmq will propagate EPIPE, I expect.

4. If, instead of using write(2), we use send(2) and specify the
  MSG_NOSIGNAL flag, then SIGPIPE will not be raised, and the send call
  will fail with EPIPE.  It sounds like modifying amqp_channel_close to
  do this might make sense: There's little value in a SIGPIPE
  when we are trying to close the connection anyway. Unfortunately,
  MSG_NOSIGNAL is only supported by some OSes.

I suspect that (3) might be your best option, at least for now.  It's
process wide, but if PHP isn't happy about getting SIGPIPE, that is
probably quite reasonable.


David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware

More information about the rabbitmq-discuss mailing list