New issue
Advanced search Search tips
Starred by 8 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 8
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment

Issue 918234: DBUS_SESSION_BUS_ADDRESS set to "disabled" even if D-Bus is running (after systemd 240)

Reported by, Dec 29

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
1. Upgrade systemd to v240
2. Run Chromium in KDE with --password-store=kwallet5

What is the expected behavior?
Chromium starts without any issue.

What went wrong?
All cookies are lost and Chromium requires signing into Google account again.

(A screenshot of some relevant log is attached - sorry for the picture, the log file got overwritten and this is all I have for now)

Did this work before? N/A 

Chrome version: 71.0.3578.98  Channel: stable
OS Version: Arch Linux, 4.19.12-zen1-1-zen
Flash Version: 

systemd 240 drops DBUS_SESSION_BUS_ADDRESS environment variable ( and expects applications to use other mechanisms to discover bus address.

Chromium sets DBUS_SESSION_BUS_ADDRESS to "disabled:" if it is empty, making itself unable to connect to D-Bus, and thus breaks kwallet5 password store.
94.2 KB View Download
Labels: Needs-Triage-M71
Components: Services>SignIn
Labels: Triaged-ET
Tentatively adding Services>SignIn. Requesting someone from the respective team to look into the issue and help us in further triaging.


Comment 4 by, Jan 7

Components: -Services>SignIn
+primiano per the history of the code that does this.

(And +me since I care about cookie stores getting lost)

Comment 5 by, Jan 8

As a follow up: systemd has restored the DBUS_SESSION_BUS_ADDRESS environment variable.

Comment 6 by, Jan 8

Status: WontFix (was: Unconfirmed)

Comment 7 by, Jan 8

Dbus had the bad habit of fork()+exec() in an async-unsafe way the daemon if not started. That causes serious problems to chrome.

Sign in to add a comment