|
|
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;
|