Bug#789118: No issues with clean upgrade

[Michel Dänzer]

On 27.06.2015 00:17, Josh Triplett wrote:
> 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.

FWIW, I indeed experienced the same problem before on an earlier major
upstream version upgrade of gnome-shell.


>> 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.

That only happens if the time between restarting gnome-shell twice is
"too short". I don't know the exact threshold, but it seems to be around
a few minutes.

Also, it's possible (at least it used to be) to close the "Oh no!"
dialogue by pressing alt-F4. Of course, that does mean the SIGHUP
workaround might potentially allow a third party to circumvent the
screen lock.

So, I agree the SIGHUP workaround probably shouldn't be done
automatically, but it might be worth at least documenting it with all
its caveats, e.g. in NEWS.Debian.gz.


> 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 .

I'm afraid live upgrades might not be a use-case GNOME upstream cares
about. :(


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer