gio backend: please don't run dbus-launch unconditionally

Bug #1622074 reported by az on 2016-09-10
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
Medium
Michael Terry

Bug Description

this is a forward of debian bug #836088, which lives over there: http://bugs.debian.org/836088
the original reporter asks for improvements in the gio/dbus interaction logic, namely this:

---
As described in <https://lists.debian.org/debian-devel/2016/08/msg00554.html>
I'm trying to reduce how much dbus-launch is used in Debian.
duplicity's gio backend currently runs dbus-launch if
DBUS_SESSION_BUS_ADDRESS is unset.

This is only a minor bug in Debian, because Debian's dbus packaging is
designed to ensure that either DBUS_SESSION_BUS_ADDRESS is set for normal
sessions, or dbus-launch isn't available anyway. However, it could cause
problems in edge cases and is probably worth fixing upstream.

One issue with the current code is that it second-guesses how dbus
itself will find the session bus. In recent libdbus and GDBus, the
fallback behaviour if DBUS_SESSION_BUS_ADDRESS is unset is to look
for $XDG_RUNTIME_DIR/bus: if the environment variable is set, that
directory contains ./bus, and ./bus is a socket owned by the current
uid, then libdbus and GDBus will automatically use it. In particular,
the dbus-user-session Debian package sets up this situation. duplicity
should not run dbus-launch without first looking for that socket.

Another issue with the approach duplicity has taken is that it relies
on dbus-launch, which is X11-specific legacy code that does several
things, none of them particularly well.
This Flatpak commit illustrates how eval `dbus-launch` can be replaced
by invoking dbus-daemon directly, avoiding the X11-specific dbus-launch:
<https://github.com/flatpak/flatpak/commit/6cc8062cfb3f9410d54a27e7ccca77c103e441e8>.
It is possible to send both the address and the pid to stdout
("--print-address=1 --print-pid=1") if that would be easier to do from
Python; their order is undocumented but predictable, and I don't intend
to break it in future D-Bus releases.

Alternatively, and perhaps most simply, duplicity could stop trying to
compensate for a missing session bus address at all. On systems with
$XDG_RUNTIME_DIR/bus, it would "just work" anyway; or when run under X11
(even with no dbus-daemon running), X11 autolaunching would create a
dbus-daemon anyway; or if duplicity is being run in a non-GUI
environment, for example from cron, its documentation could mention that
use of the gio backend sometimes requires using

    dbus-run-session -- duplicity [ARGS...]

which has been available since dbus 1.8, and automatically cleans up
the dbus-daemon after duplicity terminates (successfully or not).
---

Michael, could you look at this since you wrote the GIO parts? Thanks!

Changed in duplicity:
assignee: nobody → Michael Terry (mterry)
importance: Undecided → Medium
Michael Terry (mterry) wrote :

Hmm, indeed the original intent of that code was to support being run in cron. I'm not sure I love the idea of simply a documentation fix (telling users to manually prefix dbus-run-session).

But maybe one of the other solutions proposed can be a good fix. Or maybe a very user-friendly error message in this case, suggesting dbus-run-session, would be enough...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers