bd1529
From 9c0ed82f661a2296784970678746b0b4f130870e Mon Sep 17 00:00:00 2001
bd1529
From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
bd1529
Date: Thu, 21 Jun 2018 14:12:30 +0100
bd1529
Subject: [PATCH] core: remove support for API bus "started outside our own
bd1529
 logic"
bd1529
bd1529
Looking at a recent Bad Day, my log contains over 100 lines of
bd1529
bd1529
    systemd[23895]: Failed to connect to API bus: Connection refused
bd1529
bd1529
It is due to "systemd --user" retrying to connect to an API bus.[*]  I
bd1529
would prefer to avoid spamming the logs.  I don't think it is good for us
bd1529
to retry so much like this.
bd1529
bd1529
systemd was mislead by something setting DBUS_SESSION_BUS_ADDRESS.  My best
bd1529
guess is an unfortunate series of events caused gdm to set this.  gdm has
bd1529
code to start a session dbus if there is not a bus available already (and
bd1529
in this case it exports the environment variable).  I believe it does not
bd1529
normally do this when running under systemd, because "systemd --user" and
bd1529
hence "dbus.service" would already have been started by pam_systemd.
bd1529
bd1529
I see two possibilities
bd1529
bd1529
1. Rip out the check for DBUS_SESSION_BUS_ADDRESS entirely.
bd1529
2. Only check for DBUS_SESSION_BUS_ADDRESS on startup.  Not in the
bd1529
   "recheck" logic.
bd1529
bd1529
The justification for 2), is that the recheck is called from unit_notify(),
bd1529
this is used to check whether the service just started (or stopped) was
bd1529
"dbus.service".  This reason for rechecking does not apply if we think
bd1529
the session bus was started outside our logic.
bd1529
bd1529
But I think we can justify 1).  dbus-daemon ships a statically-enabled
bd1529
/usr/lib/systemd/user/dbus.service, which would conflict with an attempt to
bd1529
use an external dbus.  Also "systemd --user" is started from user@.service;
bd1529
if you try to start it manually so that it inherits an environment
bd1529
variable, it will conflict if user@.service was started by pam_systemd
bd1529
(or loginctl enable-linger).
bd1529
bd1529
(cherry picked from commit d3243f55ca9b5f305306ba4105ab29768e372a78)
bd1529
bd1529
Resolves: #1764282
bd1529
---
bd1529
 src/core/manager.c | 5 -----
bd1529
 1 file changed, 5 deletions(-)
bd1529
bd1529
diff --git a/src/core/manager.c b/src/core/manager.c
bd1529
index 012615e537..3c44ad3dbc 100644
bd1529
--- a/src/core/manager.c
bd1529
+++ b/src/core/manager.c
bd1529
@@ -1519,11 +1519,6 @@ static bool manager_dbus_is_running(Manager *m, bool deserialized) {
bd1529
         if (m->test_run_flags != 0)
bd1529
                 return false;
bd1529
 
bd1529
-        /* If we are in the user instance, and the env var is already set for us, then this means D-Bus is ran
bd1529
-         * somewhere outside of our own logic. Let's use it */
bd1529
-        if (MANAGER_IS_USER(m) && getenv("DBUS_SESSION_BUS_ADDRESS"))
bd1529
-                return true;
bd1529
-
bd1529
         u = manager_get_unit(m, SPECIAL_DBUS_SOCKET);
bd1529
         if (!u)
bd1529
                 return false;