Bug 1275136 - [regression] can only unlock screen by switching to vt1
[regression] can only unlock screen by switching to vt1
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-26 00:05 EDT by Hin-Tak Leung
Modified: 2016-12-20 10:09 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 10:09:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hin-Tak Leung 2015-10-26 00:05:46 EDT
Description of problem:
This seems to be a bizarre regression - in f22, I could move the mouse to wake up the screen then press esc to unlock the screen, but after upgrading to f23 a few days ago, it had not been the case. By trial and error, I managed to figure
out that if I do ctrl-alt-f1 (the usual user session is on vt2) to get at the Xwayland login-screen, and select myself again, I could unlock the screen. This is really bizarre.

I don't know why this is acceptable for release...

Version-Release number of selected component (if applicable):
gnome-shell-3.18.1-1.fc23.x86_64

How reproducible:
Always

Steps to Reproduce:
1. wait a bit for the screen to go to sleep and go blank and dark
2. try moving the mouse - the screen lights up but shows nothing (in f22 it used to show the digital clock on a blue background at this stage); pressing escape does not seem to have any effect.
3.

Actual results:
complex manoeuvre to unlock screen - ctrl-alt-f1 to get to login-screen, type in password, etc.

Expected results:
It should wake and unlock on simple key press/mouse movement.

Additional info:
upgraded through 'dnf --releasever=23 ...' if that's relevant.
Comment 1 Owen Taylor 2015-10-26 10:40:52 EDT
(In reply to Hin-Tak Leung from comment #0)
> Description of problem:
> This seems to be a bizarre regression - in f22, I could move the mouse to
> wake up the screen then press esc to unlock the screen, but after upgrading
> to f23 a few days ago, it had not been the case. By trial and error, I
> managed to figure
> out that if I do ctrl-alt-f1 (the usual user session is on vt2) to get at
> the Xwayland login-screen, and select myself again, I could unlock the
> screen. This is really bizarre.
> 
> I don't know why this is acceptable for release...

As you can imagine, this is not happening for most other people, so we need to figure out what is different with your system and why it is happening to you.

 - Are you using a wayland or X session?
 - Do any error messages appear in your journalctl logs?
 - What sort of input device are you using? It's possible this is some sort of input issue where input events aren't changing the X server out of the idle state, though if neither the keyboard or mouse has an effect, this is less likely.
Comment 2 Hin-Tak Leung 2015-10-26 10:59:17 EDT
running  X session - gnome-classic, no error message in journlctl.

It is a laptop, with its built-in touchpad.

# ps -ax | grep X
 1031 ?        Ss     0:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD
 1656 tty1     Sl+    0:00 /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displayfd 6
 2072 tty2     Sl+   35:18 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
22097 pts/2    S+     0:00 grep --color=auto X

# ps -ax | grep gdm
 1251 ?        Ssl    0:00 /usr/sbin/gdm
 1263 ?        Sl     0:00 gdm-session-worker [pam/gdm-launch-environment]
 1424 tty1     Ssl+   0:00 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session --autostart /usr/share/gdm/greeter/autostart  --session gnome-wayland
 1565 tty1     Sl+    0:00 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-wayland
 1575 tty1     Sl+    0:34 gnome-shell --mode=gdm --wayland --display-server
 1941 ?        Sl     0:00 gdm-session-worker [pam/gdm-password]
 2062 tty2     Ssl+   0:00 /usr/libexec/gdm-x-session --run-script env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic
 2072 tty2     Sl+   35:19 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
22125 pts/2    S+     0:00 grep --color=auto gdm
Comment 3 Owen Taylor 2015-10-26 11:05:27 EDT
As a test, can you try logging in to the standard (non-classic) session and see if the problem occurs there? The classic session does get enough testing that I'd expect this problem to have been reported already if that was the only trigger, but it's definitely the less common variant on Fedora.
Comment 4 Hin-Tak Leung 2015-10-27 14:29:06 EDT
(In reply to Owen Taylor from comment #3)
> As a test, can you try logging in to the standard (non-classic) session and
> see if the problem occurs there? The classic session does get enough testing
> that I'd expect this problem to have been reported already if that was the
> only trigger, but it's definitely the less common variant on Fedora.

It gets interesting - my regular account can't even start the standard session; but the wayland session sleeps and unlocks correctly AFAIS.

A separate test account also sleep and unlock like I prefer (just move mouse to wake screen and press esc) under the classic session also.

So it seems that something under my regular account is stopping the standard x session from launch, and also causing this bizarre regression under the classic session.

I have two extensions under
~/.local/share/gnome-shell/extensions/

system-monitor@paradoxxx.zero.gmail.com
weather-extension@xeked.com

both of which I have since updated to latest (which supposedly support gnome-shell 3.18) but no improvement.
Comment 5 Owen Taylor 2015-10-27 14:45:12 EDT
Any log messages when you try to log in with the standard X session?
Does disabling the extensions (from gnome-tweak-tool or the website) and logging out and logging back in help?
Comment 6 Hin-Tak Leung 2015-12-03 21:03:40 EST
I think this might be related:

Dec 03 21:58:50 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: Timeout was reached
Dec 03 21:58:50 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)
Dec 03 21:59:04 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: Timeout was reached
Dec 03 21:59:04 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)

Any idea what these messages about?

It seems that it isn't about what session, but that I always have firefox running with many windows.

There is one particular occasion which might be related - my machine goes  into suspend when power is critical; so one day everything get paged out and I plugged it back in time. But gnome-shell just won't page back in. After working in the virtual console for an hour I got fed up with it and did 'gnome-shell --replace -d :0 &'

This got my X responsive immediately. However I later found out that I could not reboot/shutdown from the new gnome-shell's menu; and there are a few mesasges on the controlling VT saying gnome-shell can't talk to dbus or something.

I think this is a timeout thing, as well as gnome-shell not running with high-enough privilege/priority, like it did before the move to X without setuid root and Xwayland.
Comment 7 Hin-Tak Leung 2015-12-30 16:54:24 EST
Switching the mouse cursor theme away from the default adwaita actually improves the situation a great deal and I can unlock the usual way most of the time after the change. I have no idea how/why.


Strangely enough, searching for:

"'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)"

on google lead to some reports about gnome-shell hanging, - on archlinux, I think - led to the advice of switching the mouse cursor theme away from the default adwaita with gnome-tweak-tool. This seems harmless enough so I gave it a try. The worst I get is a different mouse pointer I might like , right? So I did. and very surprised that it makes a lot of difference.
Comment 8 Fedora End Of Life 2016-11-24 07:55:00 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Fedora End Of Life 2016-12-20 10:09:43 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.