<div dir="ltr">In node-dbus I buffer all outgoing messages until underlying transport stream is established and then send them all at once. My guess was that EPIPE is caused by not checking backpressure properly</div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jun 3, 2015 at 9:48 AM, Chris Morgan <<a href="mailto:chmorgan@gmail.com" target="_blank">chmorgan@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jun 2, 2015 at 4:37 PM, Thiago Macieira <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote: > On Monday 01 June 2015 21:21:16 Chris Morgan wrote: >> Hello. >> >> I'm using dbus-daemon on a systemd distro built under yocto on an arm >> system, a BBB (1GHz Arm), 512MB ram, emmc. >> >> At startup we've got two clients, one c# using dbus-sharp, and another >> nodejs using node-dbus (<a href="https://github.com/sidorares/node-dbus" target="_blank">https://github.com/sidorares/node-dbus</a>) that >> are both seeing EPIPE from the dbus client socket as reported via >> strace. > > For real pipes, EPIPE indicates that you're writing while there's no pipe > reader. For sockets, that happens only when a connected socket's peer has shut > down reception. In other words, the socket has disconnected. > > dbus-daemon only disconnects you if you send invalid stuff. So I advise you to > check those two bindings for protocol correctness. > >> I'm guessing that the high cpu and io load at startup may be the cause >> of the issue. Those clients are relatively heavy to startup, one being >> mono, the other node. This particular issue isn't seen on the desktop >> under F21 or Arch with the same software. > > No, that can't be it. If the socket never connected, you'd get ENOTCONN, not > EPIPE. > >> Is there some way to debug the reason behind the EPIPE from the >> dbus-daemon side? I tried compiling with the --enable-verbose-tracing >> and enabling DBUS_VERBOSE=1 but that produces a ton of output that >> seems unrelated to the EPIPE issue. > > The message failed to parse. Use strace on your application and capture the > all the messages sent after the last time the bus sent anything to you. One of > those messages is invalid. > > -- > 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> > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > _______________________________________________ > dbus mailing list > <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/dbus" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dbus</a> </div></div>I'll do this and see if I can't get a working and non-working case. We did that before but I don't have it handy, I'll reproduce and report. Interestingly, same sw never has the issue running on the desktop environment. That would be the identical node-dbus and dbushsarp modules and code. And it appears to be related to system load. Is there anything that the comes to mind that the clients might not be handling in those particular cases? We looked into the gdbus code and didn't see any retries etc but if it is a protocol issue I'm wondering if its related to the high load and something not being handled in a corner case of the protocol. Chris <div class="HOEnZb"><div class="h5">_______________________________________________ dbus mailing list <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/dbus" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dbus</a> </div></div></blockquote></div> </div>