On Sat, 26 Aug 2017 at 09:07:55 +0100, Barak A. Pearlmutter wrote:
> This behaviour really is unacceptable, and this bug should be elevated
> in priority.
I agree that in a perfect world, D-Bus would be restartable. However,
we do not live in that perfect world. If we did, many things would work
differently. If it was as simple as "raise the bug priority and someone
will solve the problem", then it would have been resolved a decade ago.
You are welcome to try to fix this behaviour while respecting the various
constraints that exist. However, consensus among the upstream maintainers
of D-Bus (the protocol) and dbus (the reference implementation of that
protocol) is that attempting to implement state handover (re-exec) would
be sufficiently complex that the most likely result would be worse bugs
than the need to restart. In particular, it is plausible that bugs in
the re-exec handover would themselves cause security vulnerabilities.
As a result, I would suggest that your time (and the D-Bus maintainers'
time, for either implementation or review) would be better spent
elsewhere.
> I'd
> suggest that it might be easier to try to ensure that dbus is
> "crashable" or "crash-only", meaning that if the daemon is
> unexpectedly terminated with prejudice, it will be restarted
> automatically and its clients will all reestablish appropriate
> connections.
That would be an incompatible change: D-Bus implementations (both the
reference implementation dbus, and compatible reimplementations like
systemd's sd-bus and GLib's GDBus) do not reconnect, and that change
would break them. The D-Bus protocol was frozen more than 10 years
ago, so incompatible changes cannot be accepted.
Also, the application-facing API of D-Bus signals (broadcasts) cannot
work across a reconnection, because there is no way to know whether you
have missed a signal during the time between disconnection and
reconnection, and many higher-level APIs that use D-Bus rely on never
missing a signal for their correctness. A hypothetical protocol that
resembles D-Bus but is crash-safe would require application code to be
aware of reconnections, and resynchronize state after reconnection;
the lower-level code that implements the D-Bus protocol does not have
enough domain-specific knowledge to be able to resynchronize.
If you want a crash-safe IPC protocol, you are welcome to design and
implement one, but D-Bus is not and will not be that protocol. A broadly
similar but crash-safe protocol would be sufficiently different, from
an application's point of view, that it would need to have a separate
name (evencalling it something like "D-Bus 2.0" would be deeply
misleading) and would need to be implemented separately.
I know this is not the answer you want, but it's the only one I have.
Regards,
S
