Clients seeing EPIPE, dbus-daemon 1.8.16, how to debug?
chmorgan at gmail.com
Tue Jun 2 16:48:23 PDT 2015
On Tue, Jun 2, 2015 at 4:37 PM, Thiago Macieira <thiago at kde.org> wrote:
> On Monday 01 June 2015 21:21:16 Chris Morgan wrote:
>> 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
> 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
>> 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
> dbus at lists.freedesktop.org
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.
More information about the dbus