Assuming it sticks, as per
crrev.com/2865283002 (#470059), chrome disables the DBus
auto-launch feature [1]. This should affect, for the good, only testing environments like xvfb / chromedriver / selenium and not typical desktop use cases. If you start seeing weird dbus-related errors please file a bug or directly revert the CL if it's breaking bots.
If you want to get the old behavior back, set DBUS_SESSION_BUS_ADDRESS="autolaunch:".
Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS environment variable. This variable allows the dbus client library to directly connect to the existing bus started by the desktop environment or systemd.
When this variable is missing, the dbus client library will fallback to auto-launch mode [1], which causes 4 nested fork() + exec() calls to spawn a brand new dbus service and blocks the main process (chrome's browser) on the child process execution (...) after other threads have been brought up.
Doing this has two problems: (i) slows down startup / test time; (ii) can hang the browser if the fork() happens while another thread is in a malloc() (see
crbug.com/715658)
(ii) is quite subtle. The real problem is not fork() itself, but the fact that the forked process does a malloc before the exec. I filed two bugs upstream against
glib [2] and
libdbus [3] and I'll try to send a patch to fix that as soon as I have spare cycles.
As far as I know, these days the only case when DBUS_SESSION_BUS_ADDRESS is absent is test scenarios (browsertests, selenium/chromedriver, etc).
The CL linked above sets the bus address env variable to "disabled:" if not set.
This effectively shuts down the dbus auto-launch. If necessary, this behavior can be restored by setting, before launching chrome, DBUS_SESSION_BUS_ADDRESS="autolaunch:" .