Upstart spins forever when sender fails to call recv()

upstart at upstart at
Fri Mar 26 14:43:16 GMT 2010

> > I understand that the app is mistaken in dropping the socket.  But I'm
> > getting some pressure to modify upstart to close the socket when this
> > happens so we're less vulnerable to errors like this.  Are there good
> > reasons to keep the socket open in this case?  (We're on 0.3.8 thanks
> > to our build system having a really old autoconf, but the latest code
> > seems the same: errors from sendmsg() are noted but not otherwise
> > acted on.)
> > 
> What latest code are you looking at?

0.5.1 was what I looked at.

> Upstart hasn't shipped a "libupstart" for the best part of two years,
> that code is long dead and buried.
> All Upstart versions since 0.5.0 (0.6.5 is current) use D-Bus for
> communication.

0.5.1 still calls sendmsg() in nih_io_message_send(), and ignores all
errors beyond raising them.

Given that we're stuck with 0.3.8 for the time being, and so with its
socket-based IPC, would you recommend against closing sockets in cases
like this where the client is not listening?  Are there any cases
where socket errors should result in closing the socket and giving up
on whatever reply or message was meant for it?


* From the desktop of: Eric House, eehouse at                       *
*       Crosswords 4.4 for WinMobile plays over the internet:  *

More information about the upstart-devel mailing list