DBUS_SESSION_BUS_ADDRESS set to "disabled" even if D-Bus is running (after systemd 240)
Reported by
richard0...@gmail.com,
Dec 29
|
|||||
Issue descriptionUserAgent: 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 (https://github.com/systemd/systemd/commit/2b2b7228bffef626fe8e9f131095995f3d50ee3b) 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.
,
Dec 31
,
Jan 3
Tentatively adding Services>SignIn. Requesting someone from the respective team to look into the issue and help us in further triaging. Thanks.!
,
Jan 7
+primiano per the history of the code that does this. (And +me since I care about cookie stores getting lost)
,
Jan 8
As a follow up: systemd has restored the DBUS_SESSION_BUS_ADDRESS environment variable.
,
Jan 8
,
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 |
|||||
Comment 1 by pryka.il...@gmail.com
, Dec 30