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

Bug #1622074 reported by az
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
New
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).
---

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

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

Changed in duplicity:
assignee: nobody → Michael Terry (mterry)
importance: Undecided → Medium
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.