<div dir="ltr">On Wed, Nov 7, 2018 at 4:49 PM Simon McVittie <<a href="mailto:smcv@collabora.com">smcv@collabora.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - Is there a way to grab more info anywhere /why/ the GBusNameLostCallback<br>
>   event occurred?<br>
<br>
No, there is currently no protocol by which the dbus-daemon can tell<br>
a client *why* that client is getting disconnected: fatal errors just<br>
disconnect the socket. Implementing this would not necessarily be<br>
straightforward, because the dbus-daemon would need to be able to stop<br>
reading from the client, but keep the connection alive long enough to<br>
do all the asynchronous send operations for at least the rest of the<br>
current partially-sent message if any (to avoid corrupting the stream by<br>
inserting the error into the middle of an unrelated message), followed<br>
by the error, followed by disconnection.<br>
<br>
Messages can be large enough that they need to be sent in multiple<br>
sendmsg() transactions (or even large enough that they exceed the socket<br>
buffer), so we have to get the framing right, and we have to do it all<br>
asynchronously.<br></blockquote><div><br></div><div>For what it is worth, dbus-broker allows this, and in many cases it does. However, in this particular situation it would also not return an error before disconnecting. The reason we did not (so far) is that we thought that if the error was in parsing the message (which this would fall under), then it would not always be the case that we would even be able to read the serial to reply to (and we really don't want to be doing unsolicited errors, as clients simply wouldn't to expect them). It may make sense to be a bit more clever about this though, and reply with an error whenever we are able to (as this kind of situation is really not easy to debug).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I dimly remember once trying to prototype a feature where dbus-daemon<br>
would try to add a signal or an unsolicited error message into the<br>
sending socket before disconnecting clients, but it ended up sufficiently<br>
complicated that I wasn't confident that it was right. Client libraries<br>
would also have to be modified to look for those messages and use them<br>
to populate a more specific error indicator.<br></blockquote><div><br></div><div>Yeah, I think we would have to restrict ourselves to replying with errors to method calls that expect a reply, otherwise it would get really complicated on the client side.<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Tom<br></div></div></div>