gio backend: please don't run dbus-launch unconditionally
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://
the original reporter asks for improvements in the gio/dbus interaction logic, namely this:
---
As described in <https:/
I'm trying to reduce how much dbus-launch is used in Debian.
duplicity's gio backend currently runs dbus-launch if
DBUS_SESSION_
This is only a minor bug in Debian, because Debian's dbus packaging is
designed to ensure that either DBUS_SESSION_
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_
for $XDG_RUNTIME_
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:/
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_
(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-
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!