Bug#789118: No issues with clean upgrade

[Josh Triplett]

On Fri, Jun 26, 2015 at 11:42:44AM +0200, Emilio Pozuelo Monfort wrote:
> Control: found -1 3.14.4-1
> 
> On 22/06/15 02:36, Michel Dänzer wrote:
> > On 22.06.2015 03:39, Josh Triplett wrote:
> >> On Sun, Jun 21, 2015 at 07:52:10PM +0200, Michael Biebl wrote:
> >>> Am 20.06.2015 um 08:54 schrieb Michel Dänzer:
> >>>> On Thu, 18 Jun 2015 21:19:20 +0400 George Hertz <georgedot at gmail.com> wrote:
> >>>>> I've just upgraded to 3.16 on unstable, but restarted the system right 
> >>>>> after the update finished.
> >>>>>
> >>>>> No problems unlocking.
> >>>>
> >>>> Yeah, the problem only occurs with a gnome-shell which is already
> >>>> running during the upgrade.
> >>>>
> >>>> However, the problem also occurs when only locking the session after the
> >>>> upgrade has completed.
> >>>>
> >>>> One possible workaround after the upgrade is
> >>>>
> >>>> 	killall -HUP gnome-shell gnome-settings-daemon
> >>
> >> I didn't know you could HUP gnome-shell to unlock the session; that's
> >> useful to know.
> >>
> >>>> Sending SIGHUP to gnome-shell only is enough to be able to unlock the
> >>>> session, but gnome-settings-daemon also needs to be restarted, or some
> >>>> things such as keyboard shortcuts don't work properly in the new
> >>>> gnome-shell.
> >>>
> >>> Unfortuantely we don't have a proper mechanism to restart programs in
> >>> the desktop session. Using killall in postinst is something I'd be wary
> >>> about.
> >>
> >> It's also not OK to unexpectedly unlock someone's session due to a
> >> concurrent upgrade; "can't unlock my session" is bad, but "unlocked my
> >> screen during upgrade" is a critical security bug.
> > 
> > SIGHUP doesn't unlock the session, it just makes gnome-shell restart
> > itself, after which the upgraded version of gnome-shell runs and
> > unlocking the session works normally.
> 
> This bug is preventing testing migration, which is causing a lot of other bugs
> because of version mismatches between gtk+, gnome-settings-daemon and
> mutter/gnome-shell (see e.g. #789618, #789891, #789866, #789725, #789575,
> #789484...). I've talked about it to some team members and we agreed that this
> is RC, but that it'd be better to let gnome-shell migrate for the time being. So
> I'm doing some trick to let it migrate, but we'll fix this.

I wouldn't be surprised if the bug exists in previous versions of
gnome-shell as well, so allowing migration to testing seems fine.  (Or
actually, it's not obvious whether the bug exists in current versions,
as it's the previous version which failed to unlock after upgrade.)  The
new version likely isn't any more broken than the old; it's the upgrade
that's broken, and preventing that upgrade indefinitely doesn't make the
problem go away.

(Also, those other bugs seem to indicate that either the interactions
between those components need to be made less fragile, or package
dependencies need to prevent installing incompatible versions.)

> Josh, any chance you can try the SIGHUP approach and confirm that solves your
> problem and doesn't cause any other undesired effect?

I've tested sending a SIGHUP to gnome-shell, and that approach causes
several significant undesired effects.

1) Sending SIGHUP to gnome-shell momentarily drops the screen lock.
This reveals the applications behind the screen lock, and even allows
interacting with them.  (For a fraction of a second, sure, but still,
that's a security issue.)

2) If gnome-shell restarts twice in the same session, the second time it
puts up the "Oh no!" dialog, which only allows the user to restart their
session, losing anything they have open.  So if gnome-shell has
already restarted once in the user's session for unrelated reasons,
sending SIGHUP to it will force the user to restart their session
entirely and lose any open applications.

Based on the above, I think it'd be an extremely bad idea to send SIGHUP
to a user's gnome-shell from a maintainer script.

I think it's going to be necessary to teach gnome-shell to handle screen
unlocking after an upgrade.  I've forwarded this bug upstream to
https://bugzilla.gnome.org/show_bug.cgi?id=751544 .

- Josh Triplett