Re: Clients seeing EPIPE, dbus-daemon 1.8.16, how to debug?

In node there is standard way of handling backpressure ( automatically via
`pipe()` chains or by checking write() result and reacting on "drain" event.

Have not added fix as problem disappeared for user after updating to daemon
1.8.16 , but it's in my todo

On Wed, Jun 3, 2015 at 9:59 AM, Chris Morgan <[email protected]> wrote:

> 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
>
>
>
> On Tue, Jun 2, 2015 at 7:54 PM, Andrey Sidorov <[email protected]>
> 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 <[email protected]> wrote:
> >>
> >> On Tue, Jun 2, 2015 at 4:37 PM, Thiago Macieira <[email protected]> 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 (https://github.com/sidorares/node-dbus) 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) macieira.info - thiago (AT) kde.org
> >> >    Software Architect - Intel Open Source Technology Center
> >> >       PGP/GPG: 0x6EF45358; fingerprint:
> >> >       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
> >> >
> >> > _______________________________________________
> >> > dbus mailing list
> >> > [email protected]
> >> > http://lists.freedesktop.org/mailman/listinfo/dbus
> >>
> >>
> >> 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
> >> [email protected]
> >> http://lists.freedesktop.org/mailman/listinfo/dbus
> >
> >
>

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus