Comment 16 for bug 1618886

Revision history for this message
Iain Lane (laney) wrote : Re: [Bug 1618886] Re: unity-gtk-module.service is racy; session services don't stop if session terminates

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 [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]