<div dir="ltr">In node there is standard way of handling backpressure ( automatically via `pipe()` chains or by checking write() result and reacting on "drain" event.<div> </div><div>Have not added fix as problem disappeared for user after updating to daemon 1.8.16 , but it's in my todo </div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jun 3, 2015 at 9:59 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">Hmm. Did you have a fix for that in mind? I should be able to manufacture a better test case for that here by adding even more dbus calls when our script starts up. Chris <div class="HOEnZb"><div class="h5"> On Tue, Jun 2, 2015 at 7:54 PM, Andrey Sidorov <<a href="mailto:andrey.sidorov@gmail.com">andrey.sidorov@gmail.com</a>> wrote: > 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 > > On Wed, Jun 3, 2015 at 9:48 AM, Chris Morgan <<a href="mailto:chmorgan@gmail.com">chmorgan@gmail.com</a>> wrote: >> >> 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> >> >> >> 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 >> _______________________________________________ >> 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>