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

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