ignoring a process' last words: SIGPIPE ...
hp at pobox.com
Thu Mar 27 11:13:20 PDT 2008
On Thu, Mar 27, 2008 at 1:53 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
> In general, most Internet protocols are designed around this rule by
> having the client *request* disconnection, and then having the server
> disconnect only after receiving this request. That way, neither end
> is surprised.
Both ends need to deal with the other end crashing or disconnecting. I
would think adding a "clean" way to disconnect just creates another
special case. It's a bug if a "dirty" or "abrupt" disconnect doesn't
work, so the single, only codepath to test may as well be "just close
> In this case, dbus-send is disconnecting without telling the server,
> and the server doesn't deal well with the surprise.
Which is a bug, even if there is a clean way to disconnect.
> One perfectly good solution, as proposed already, is to use the
> --print-reply option to dbus-send, which forces it to stay connected
> until it gets the answer back. In fact, this isn't such a bad idea
> either way.
What I meant on this btw was not to use --print-reply, but make
dbus-send block for reply even if it will not be printing the reply.
The idea of method replies has always been that to reliably send a
method call and know it happened, you need the ack.
> In the case of dbus-daemon, I'd think it should be safe to just ignore
> EPIPE and pretend the data has been written. Remember, the socket
> isn't really "closed" until you close it, and the fd will remain valid
> and won't be reused, so there's no reason to throw away any
> authentication data structures, etc. The socket will close just fine
> next time through the normal execution path where select() returns
> true for readable, and then read() returns 0 bytes (EOF).
This may be part of the solution. I would be pretty worried about
introducing bugs, though, if this were not done very carefully. It
would definitely need test cases to be added and all uses of
connection_get_connected(), transport_get_connected(), etc. audited to
see if they "really meant" connected for read or for write. We would
also have to think about possible accidental changes to public API
semantics. I don't know. It seems like it's a lot of work to verify
that this change is OK. Perhaps it is less work than figuring out how
to force immediate read-and-dispatch of remaining incoming messages on
disconnect. But either way is a fair bit of work, unless we just
change it and hope for the best without adding tests or carefully
reviewing the effect on existing API and codepaths.
More information about the dbus