On Sat, Oct 01, 2016 at 01:53:56PM -0000, Martin Pitt wrote: > > To fix that, something like comment #3 is needed. Such as looping over > all 'active' units that are PartOf graphical-session.target and stopping > them all. > > I think we would only need to "systemctl stop graphical-session.target" > for this, otherwise a unit forgets the PartOf= and that loop would not > work anyway.
I tried this, but I think that it might have only been before I worked out the below ExecStopPost issue - so it's worth testing again. > > > gnome-session needs a fix to its ExecStopPost to not kill the one we > just started. > > This is similar to waiting for "deactivating" units after > *-session.target goes down. On the systemd sprint we just figured out a > better scheme for this which solves that waiting, does not require this > session ID tracking, and also gets rid of the manual starting of > graphical-session-pre.target: Eventually we just want to declare in > *-session.target that it comes After=graphical-session-pre.target and > have this propagate to the dependencies > (https://github.com/systemd/systemd/issues/3750). Until then we can just > have a mini-generator do this for us. After we have the Requires/After > =graphical-session-pre.target, then "systemctl stop graphical-session- > pre.target" properly blocks until all "later" units are completely > stopped. I remember this problem. It would only solve this specific issue if it lets us get rid of the stop or restart in the session-runner script. If you ever end up stopping gnome-keyring from within a new session then its ExecStopPost kills the upstart session of this new one that we are starting up, *not* the previous one that it was started up under. That's a mismatch vs. session and user specific semantics of upstart and systemd --user. Hmm. Maybe this is saying that we should bind ubuntu-session.target to something else - like unity7? You can't log in again with an active unity7, so in theory (if stop is propagated down to graphical-session and graphical-session-pre) there wouldn't be a need to stop/restart in the script since everything would be stopped by definition if you're trying to start unity7 again. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-session in Ubuntu. https://bugs.launchpad.net/bugs/1618886 Title: unity-gtk-module.service is racy; session services don't stop if session terminates Status in gnome-session package in Ubuntu: Fix Released Status in unity-gtk-module package in Ubuntu: Fix Released Status in upstart package in Ubuntu: Triaged Bug description: Sometimes on session start unity-gtk-module.service runs too late or something, and $GTK_MODULES does not include "unity". It is in "systemctl --user show-environment" but not in a terminal bash. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1618886/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
