On Thu, Jun 2, 2016 at 9:01 AM, Ray Strode <halfline(a)gmail.com> wrote:
Of course, starting in Fedora 24, we no longer have a session bus.
It's a user bus now. So the bus won't go away until the last user
session (for a user) ends, and those background services won't go away
until they lose their bus connections, since they still rely on
dbus-daemon to cut the cord when the session ends. While those
background services are waiting for their bus connection to disappear,
they're keeping the session alive (but in a "closing" state).
Sounds familiar. While it's not reproducible in a VM, on two baremetal
systems I can reproduce 1m30s restart/shutdown delays on defaut clean
To me, KillUserProcesses=yes is better from a theoretical
it-should-have-always-done-this-if-it-could-have standpoint, and it's
better from real world
KillUserProcesses=yes isn't solving the problem I'm easily able to
reproduce, because it isn't killing the gdm owned session-c1.scope,
which appears to hang due to ibus-daemon not quitting.
There's a gdm owned ibus-daemon process, and a chris owned one. With
the default of KillUserProcesses=no, restart shutdown and logout are
delayed. If I set it to yes, the logout problem is fixed, but the
restart and shutdown delays aren't fixed.
I don't like that it requires users to have to change workflows, so
that's a negative and I understand why the change is controversial.
We may want to consider reverting the user bus change for F24 and
revisit in F25, not sure.
Well it's uncertain to me whether the testers so far are just
desensitized to restart delays or if they're just not encountering it,
and it's a conditional problem. If it's encountered broadly and is
fixable some reasonable time after release (a month? two?) fine. But
already I'm in the habit of rebooting Fedora 24 with 'sudo reboot -f'
because I don't have 30 seconds of patience in me let alone nearly two
minutes. But I think we're stuck between a rock and hard place between
excessive restart delays and reversion this late in the game.