On Tuesday, June 2, 2015, Thiago Macieira <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tuesday 02 June 2015 19:48:23 Chris Morgan wrote:<br>
> Is there anything that the comes to mind that the clients might not be<br>
> handling in those particular cases? We looked into the gdbus code and<br>
> didn't see any retries etc but if it is a protocol issue I'm wondering<br>
> if its related to the high load and something not being handled in a<br>
> corner case of the protocol.<br>
<br>
The protocol does not support retries. This is all done on top of a reliable-<br>
delivery streaming connection (Unix SOCK_STREAM sockets), so there's no need<br>
to retry.<br>
<br>
There's *nothing* the daemon can do to cause an EPIPE, besides disconnecting<br>
the socket.<br>
<br>
So there are two possibilities only: either EPIPE was caused by the socket<br>
being disconnected or it was caused by the kernel. If it was caused by the<br>
kernel, it's important to know what exactly the payload of the sendmsg call<br>
was.<br>
<br>
Did the payload include file descriptors? I don't see how that could cause<br>
EPIPE, but...<br>
<br>
In fact, I don't see anything else that could cause EPIPE in the kernel source<br>
code.<br>
--<br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" target="_blank">kde.org</a><br>
   Software Architect - Intel Open Source Technology Center<br>
      PGP/GPG: 0x6EF45358; fingerprint:<br>
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358</blockquote><div><br></div><div><br></div><div>I'll try to get back tomorrow sometime with the strace output<span></span>, I'm in U.S. EST time zone btw.</div><div><br></div><div>Chris</div><div> </div>