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