I've been looking at a problem on an embedded system that uses upstart. An app is using libupstart, calling nih_io_message_send() to send upstart a message (an emit, I think) to which upstart expects to reply. The app, however, never calls nih_io_message_recv(); rather, it drops the socket on the floor in effect. Upstart then spins forever trying to reply. It gets ECONNREFUSED back from sendmsg() every time, but because the socket keeps coming back writable from select() it keeps trying.
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.) Thanks, --Eric -- ****************************************************************************** * From the desktop of: Eric House, [email protected] * * Crosswords 4.4 for WinMobile plays over the internet: xwords.sf.net * ****************************************************************************** -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
