+++ This bug was initially created as a clone of Bug #1112982 +++ Description of problem: Locks the screen for the day, return the next morning, when trying to log in the screen flickers, and when you try to enter something a black dot show up, but is immediately removed, i.e. making it impossible to log in. If I enter ctrl-alt-backspace gdm is restarted, but when I try to log in (the password thing works this time, and the password is accepted), I am greeted with a totally grey screen and nothing more happens. The only way to resolve this is to restart the machine. The reason for not logging out, only locking the screen is to retain the work I am doing. By not being able to log in, and having to restart gdm with ctrl-alt-backspace I loose work. This is not acceptable. Version-Release number of selected component (if applicable): gdm-3.10.0.1-1.fc20.x86_64 systemd-208-19.fc20.x86_64 How reproducible: "once in a blue moon" (a couple of times per month) Steps to Reproduce: 1. See above Additional info: During the night the following packages were updated by yum: Jun 25 03:43:31 Updated: systemd-libs.x86_64 208-19.fc20 Jun 25 03:43:36 Updated: systemd.x86_64 208-19.fc20 Jun 25 03:43:40 Updated: wireshark.x86_64 1.10.7-3.fc20 Jun 25 03:44:12 Updated: wireshark-gnome.x86_64 1.10.7-3.fc20 Jun 25 03:44:13 Updated: systemd-python3.x86_64 208-19.fc20 Jun 25 03:44:13 Updated: systemd-python.x86_64 208-19.fc20 Jun 25 03:44:14 Updated: libgudev1.x86_64 208-19.fc20 Jun 25 03:44:14 Updated: perl-Filter.x86_64 1:1.50-1.fc20 Jun 25 03:44:15 Updated: youtube-dl.noarch 2014.06.24.1-1.fc20 Jun 25 03:44:15 Updated: htop.x86_64 1.0.3-3.fc20 Jun 25 03:44:16 Updated: libbluray.x86_64 0.6.0-1.fc20 Could this be systemd related? --- Additional comment from Aurelien GUERSON on 2014-06-25 10:52:33 UTC --- I have the same problem. See this. https://bugzilla.redhat.com/show_bug.cgi?id=1002464 you are right ;). Waiting for an issue. --- Additional comment from Aurelien GUERSON on 2014-06-25 11:00:23 UTC --- And here : https://bugzilla.gnome.org/show_bug.cgi?id=729246 --- Additional comment from Adam Williamson on 2014-06-26 06:04:00 UTC --- it would be very helpful if you could provide logs from a period where this bug kicked in; journalctl should be able to find them (you may wish to use the --since and --until parameters, if you remember the rough days and times that were affected, to help narrow down your search). Thanks. --- Additional comment from Lars E. Pettersson on 2014-06-26 17:22:21 UTC --- What part do you need? Something happened between when I left work, and when I returned the day after. That's a lot of data and a lot of IP-numbers/hostnames to remove. Or is it OK with just the part when I tried to log in? And perhaps the update of systemd? --- Additional comment from Adam Williamson on 2014-06-26 21:03:04 UTC --- ideally both the part where 'something happened' (as close as you can identify it), and the part when you try and log in again. but if you can't identify or separate out from sensitive data the first bit, the second would still be useful, I believe. you could possibly try looking for messages from particular components or services - GDM/GNOME related stuff. --- Additional comment from Aurelien GUERSON on 2014-06-27 08:09:59 UTC --- The problem seems to come from systemd see this : https://bugzilla.redhat.com/show_bug.cgi?id=1002464 but there is not patch :( --- Additional comment from Adam Williamson on 2014-06-27 15:39:24 UTC --- Are you saying what you're seeing is https://bugzilla.gnome.org/show_bug.cgi?id=729246 ? The patch you linked - https://bugzilla.gnome.org/attachment.cgi?id=278429 - is attached to that bug. --- Additional comment from Adam Williamson on 2014-06-27 15:46:01 UTC --- and, in the upstream bug, you referred to yet a different downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1092274 which you haven't mentioned here or in 1002464. It's rather difficult to tell exactly what you think is going on here. --- Additional comment from Aurelien GUERSON on 2014-07-01 07:37:29 UTC --- You are right. I have two bugs on Fedora 20 and I did some mistake with copy/paste on the links :) This bug is for the problem of locked screen. --- Additional comment from Lars E. Pettersson on 2014-07-02 19:13:59 UTC --- This is an excerpt from the log from when I left work, returned the next morning, and restarted the machine due to not being able to log in. In the middle of the night some packages (including systemd) was updated that might have something to do with problem. --- Additional comment from on 2014-07-09 19:19:21 UTC --- I confirm the bug on a headless F20 installation. Access is done via x0vncserver and Vinagre, following http://www.janbambas.cz/headless-fedora-20-and-vnc-with-autologin Deleting all journallogs as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1002464#c17 doesn't help for me. Yum is supersuper slow since fedup from F19, but this probably another issue. My journalctl -af output when trying to unlock is attached. --- Additional comment from on 2014-07-09 19:20:16 UTC --- For comment #11 --- Additional comment from Adam Williamson on 2014-07-10 04:54:49 UTC --- llarevo gets: Jul 09 20:50:47 $HOSTNAME gdm[909]: GdmSlave: could not fetch type of session 'c1': Datei oder Verzeichnis nicht gefunden Lars gets something like: Jun 25 09:16:58 some.site.se gnome-session[25824]: (gnome-shell:26063): Gjs-WARNING **: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available they don't seem to be the same issue, and neither seems to be the same as #1002464 ... but that's just my inexpert opinion. Ray, could you take a look and see what you think? Thanks. --- Additional comment from on 2014-07-10 16:44:56 UTC --- OK, Adam, the original bug https://bugzilla.redhat.com/show_bug.cgi?id=1002464 was entitled "cannot unlock gnome lock screen" which describes my problem much better. Should I post in e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1098740 which seems to be a more similar problem to mine? --- Additional comment from Adam Williamson on 2014-07-23 05:11:45 UTC --- llarevo: possibly. your error is slightly different from those in #1098740 and #960149, but both those bugs and your case do involve VNC, so it's quite possible they're related / the same. I will talk to Ray about the possibility of backporting those fixes. --- Additional comment from Lars E. Pettersson on 2014-07-23 10:03:41 UTC --- It happened again yesterday, now during the day, also this time during an update of systemd, so perhaps we have yet another bug in systemd? I will shortly attach the log for the time when this happened. These are the updated packages: abrt-addon-ccpp.x86_64 2.2.2-1.fc20 abrt-addon-kerneloops.x86_64 2.2.2-1.fc20 abrt-addon-pstoreoops.x86_64 2.2.2-1.fc20 abrt-addon-python3.x86_64 2.2.2-1.fc20 abrt-addon-python.x86_64 2.2.2-1.fc20 abrt-addon-vmcore.x86_64 2.2.2-1.fc20 abrt-addon-xorg.x86_64 2.2.2-1.fc20 abrt-dbus.x86_64 2.2.2-1.fc20 abrt-desktop.x86_64 2.2.2-1.fc20 abrt-gui-libs.x86_64 2.2.2-1.fc20 abrt-gui.x86_64 2.2.2-1.fc20 abrt-libs.x86_64 2.2.2-1.fc20 abrt-plugin-bodhi.x86_64 2.2.2-1.fc20 abrt-python3.x86_64 2.2.2-1.fc20 abrt-python.x86_64 2.2.2-1.fc20 abrt-retrace-client.x86_64 2.2.2-1.fc20 abrt.x86_64 2.2.2-1.fc20 ceph-libs.x86_64 0.81.0-5.fc20 ceph.x86_64 0.81.0-5.fc20 erlang-ibrowse.x86_64 4.0.1-1.fc20 libgudev1.x86_64 208-20.fc20 libreport-cli.x86_64 2.2.3-1.fc20 libreport-fedora.x86_64 2.2.3-1.fc20 libreport-filesystem.x86_64 2.2.3-1.fc20 libreport-gtk.x86_64 2.2.3-1.fc20 libreport-newt.x86_64 2.2.3-1.fc20 libreport-plugin-bugzilla.x86_64 2.2.3-1.fc20 libreport-plugin-kerneloops.x86_64 2.2.3-1.fc20 libreport-plugin-logger.x86_64 2.2.3-1.fc20 libreport-plugin-reportuploader.x86_64 2.2.3-1.fc20 libreport-plugin-ureport.x86_64 2.2.3-1.fc20 libreport-python3.x86_64 2.2.3-1.fc20 libreport-python.x86_64 2.2.3-1.fc20 libreport-web.x86_64 2.2.3-1.fc20 libreport.x86_64 2.2.3-1.fc20 openssh-clients.x86_64 6.4p1-5.fc20 openssh-server.x86_64 6.4p1-5.fc20 openssh.x86_64 6.4p1-5.fc20 perl-Date-Manip.noarch 6.46-1.fc20 smartmontools.x86_64 1:6.2-6.fc20 stunnel.x86_64 5.02-1.fc20 systemd-libs.x86_64 208-20.fc20 systemd-python3.x86_64 208-20.fc20 systemd-python.x86_64 208-20.fc20 systemd.x86_64 208-20.fc20 xorg-x11-drv-qxl.x86_64 0.1.1-4.fc20 youtube-dl.noarch 2014.07.20.2-1.fc20 --- Additional comment from Lars E. Pettersson on 2014-07-23 10:16:15 UTC --- journalct output from 11:00 local time until just before I wrote restart in a terminal window (ctrl-alt-F2). My login attempts starts at 12:48, and include things like switching between terminal window and graphical system (ctrl-alt-F1/F2), restarting the graphical system using ctrl-alt-backspace, etc. --- Additional comment from Adam Williamson on 2014-07-23 17:04:48 UTC --- sure, let's throw lars' case at systemd for now. --- Additional comment from Jóhann B. Guðmundsson on 2014-07-23 17:56:55 UTC --- Why not wait until Ray had commented on this not being an GDM issue? --- Additional comment from Adam Williamson on 2014-07-23 18:02:15 UTC --- oh, sorry, forgot to mention - he did, on IRC: "23-07-2014 09:58:54 < halfline!~rstrode.com: note https:// bugzilla.redhat.com/show_bug.cgi?id=1112982#c11 sounds a lot like a systemd issu e that was fixed months ago. maybe reemerged ?" --- Additional comment from on 2014-07-23 18:18:59 UTC --- Adam: I can do further testing or try to give more information or even post another bug as soon as I get a little guidance about appropriate next steps. Thank you! --- Additional comment from Jóhann B. Guðmundsson on 2014-07-23 19:38:12 UTC --- I'm not forseeing logind have been tampered with but Zbyszek more familiar with the release in Fedora and if he has introduce any patches downstream that might break it. In respone to Lars since I think the issue llavero is different and he should just add himself to #912892 since it's an pure vnc/gnome issue anyway I lock my screen like gazilion times a day ( meetings lunch etc ) and I'm running pretty stock setup of Fedora 20 here and I'm not seeing this issue gdm-3.10.0.1-1.fc20.x86_64 systemd-208-20.fc20.x86_64 So I think the locking and unlocking is not the issue here it's something spesific to Lars setup so Lars can you simply lock and unlock the screen.? And what can you tell us about your setup? Are you using stock GDM/Gnome, local user etc? What does the output from "loginctl list-sessions && loginctl list-users && loginctl user-status <your user>" say? --- Additional comment from Lars E. Pettersson on 2014-07-23 20:15:25 UTC --- Jóhann, it has happened on two different machines (they happen to both be Dell T1650, but that should not matter, I think). It has happened when I have deliberately locked the screen (the first attachment is one of those), and also when the screen has been locked by the screen-saver (the second attachment is one of those). These are also the two last occurrences of this problem. I frankly do not remember when I first saw this, but it is rather close in time. I can take a look in the logs to see if I find something to pin-point when it started. I also lock my screen a gazillion times per day. That's why this is so strange, and annoying. Coming back to the system with a password prompt with a life of its own, that makes it impossible to log in in, is really frustrating, when it works all the other times. The only common thing I have seen when this happens is that yum-cron have updated the system automatically while the system has been locked (by me or via the screen saver), and that it has updated systemd (that seem to restart a whole lot of things). My suspicion is that one of all these restarts by systemd creates the problem. I am using GDM/Gnome, rpmfusion repositories enabled. Nothing strange at all. On the work machine I have one local user. On the machine at home I have two users. $ rpm -q gdm systemd gdm-3.10.0.1-1.fc20.x86_64 systemd-208-20.fc20.x86_64 Are you using yum-cron? Or any other way to do automatic updating of your system? If not, that might be the reason you are not seeing the issue. I'll give you the result of "loginctl list-sessions && loginctl list-users && loginctl user-status lars" when I am at work and logged in tomorrow. --- Additional comment from Lars E. Pettersson on 2014-07-24 07:25:46 UTC --- Output of: loginctl list-sessions && loginctl list-users && loginctl user-status lars --- Additional comment from Anna on 2014-08-07 10:00:55 UTC --- I am also having problems with a bug that sounds like this. When logging into gnome on a previously locked gnome session on tigerVNC. If I start a new VNC server instance then I can access fine as it is not locked, but once the gnome session is locked I have the the issue where I cannot type the password because it is flickering like someone is holding the enter key down and I get the Authentication Error message. I have to kill that VNC instance and I lose everything I was running. $ rpm -q gdm systemd tigervnc gdm-3.10.0.1-1.fc20.x86_64 systemd-208-21.fc20.x86_64 tigervnc-1.3.0-14.fc20.x86_64 --- Additional comment from joseph on 2014-08-18 14:46:58 UTC --- Exact same issue here, adding since this seems to have been going on for quite some time now. I have several F20 VM's (vSphere 5.5) all of which exhibit this behavior and all of which now have to be managed from the console so now I have to grant vCenter access to many folks that really shouldn't be there. What I haven't seen mentioned (or perhaps I missed) is that once I attempt to unlock with VNC (display:1 getting 'Authentication Error' constantly) the virtual console (display:0) also stops responding completely and the only way to even get that to start responding again is to ssh in and reboot, just killing the vncserver will not do it. Also, when this happens, the gnome-shell process for that user spikes to 99%CPU and remains there until vncserver@:1 is kill or restarted. --- Additional comment from Cyril Bouteille on 2014-09-04 16:00:00 UTC --- I run into this issue when I try to replace gnome-shell after it hangs due to https://bugzilla.redhat.com/show_bug.cgi?id=812624 I ssh from another terminal to: $ DISPLAY=:1 gnome-shell --replace& which revives my UI but then the next day when the screen is locked, it flickers auto-submitting the password and I don't get a chance to type it in fully. The gnome-shell output keeps spitting: (gnome-shell:1858): Gjs-WARNING **: JS ERROR: Failed to open reauthentication channel: [boxed instance proxy GIName:GLib.Error jsobj@0x7fcaf817c4c0 native@0x5385510] System: Linux stormbringer 3.15.10-200.fc20.x86_64 #1 SMP Thu Aug 14 15:39:24 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux --- Additional comment from Lars E. Pettersson on 2014-11-17 09:00:59 UTC --- OK, it happened again! Left work on Friday, and returned Monday with a password prompt that has a life of its own, not letting me log in (it's like if something is sending returns over and over again, not letting my complete my password) This time I tried to kill systemd-logind and when I did this twice (logging in via a terminal, ctrl-alt-F2), I could log in again. But when the lock screen was activated the next time, the problems while logging in in returned. Killing systemd-logind twice, yet another time, made it possible to log in again. As I have to use this computer, I closed all my applications and rebooted. The following packages were updated after I left work on Friday: Nov 15 17:01:48 Updated: libreoffice-ure.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:01:50 Updated: systemd-libs.x86_64 208-28.fc20 Nov 15 17:01:53 Updated: systemd.x86_64 208-28.fc20 Nov 15 17:01:55 Updated: system-config-printer-libs.noarch 1.4.7-1.fc20 Nov 15 17:01:56 Updated: openssh.x86_64 6.4p1-6.fc20 Nov 15 17:01:56 Updated: autocorr-en.noarch 1:4.2.7.2-6.fc20 Nov 15 17:01:56 Updated: vpnc-script.noarch 0.5.3-21.svn550.fc20 Nov 15 17:01:57 Updated: libreoffice-opensymbol-fonts.noarch 1:4.2.7.2-6.fc20 Nov 15 17:02:37 Updated: libreoffice-core.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:38 Updated: libreoffice-impress.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:39 Updated: libreoffice-graphicfilter.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:39 Updated: libreoffice-draw.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:40 Updated: libreoffice-pdfimport.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:41 Updated: libreoffice-writer.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:43 Updated: libreoffice-calc.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:44 Updated: libreoffice-xsltfilter.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:45 Updated: libreoffice-pyuno.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:46 Updated: libreoffice-math.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:46 Updated: libreoffice-filters.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:46 Updated: libreoffice-emailmerge.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:47 Updated: libreoffice-base.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:48 Updated: libreoffice-ogltrans.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:48 Updated: libreoffice-langpack-en.x86_64 1:4.2.7.2-6.fc20 Nov 15 17:02:48 Updated: vpnc.x86_64 0.5.3-21.svn550.fc20 Nov 15 17:02:49 Updated: openssh-clients.x86_64 6.4p1-6.fc20 Nov 15 17:02:49 Updated: openssh-server.x86_64 6.4p1-6.fc20 Nov 15 17:02:51 Updated: system-config-printer.x86_64 1.4.7-1.fc20 Nov 15 17:02:51 Updated: system-config-printer-udev.x86_64 1.4.7-1.fc20 Nov 15 17:02:52 Updated: systemd-python3.x86_64 208-28.fc20 Nov 15 17:02:52 Updated: libmtp.x86_64 1.1.8-1.fc20 Nov 15 17:02:53 Updated: systemd-python.x86_64 208-28.fc20 Nov 15 17:02:53 Updated: libgudev1.x86_64 208-28.fc20 --- Additional comment from Adam Williamson (Fedora) on 2014-11-21 17:17:00 UTC --- So - the packages got updated automatically (cron job or similar) while the screen was locked? --- Additional comment from Lars E. Pettersson on 2014-11-21 18:32:02 UTC --- Correct! Have cron job that runs yum, and it ran while the screen was locked. The only common packages being updated when this have happend has been systemd related. Apparently the systemd packages triggers something while being updated, that creates problems if you have your screen locked. --- Additional comment from Adam Williamson on 2014-11-21 20:06:45 UTC --- systemd's %post does do a lot of stuff, yeah. It seems a reasonable place to start looking. --- Additional comment from Fedora End Of Life on 2015-05-29 12:12:55 UTC --- This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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. --- Additional comment from Fedora End Of Life on 2015-06-29 21:19:01 UTC --- Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. --- Additional comment from Manoj Kumar on 2017-09-15 05:12:23 UTC --- Hi, I am Manoj Kumar, Working as a system admin. Yesterday all of sudden all the employees who are working on VNC got the same issue on Redhat 7.2.They were not able to enter the password at login after screen lock. Kindly help as few employees were working in a critical project and they need to recover the terminal. --- Additional comment from Dave Neary on 2017-09-15 13:21:50 UTC --- I can confirm that this issue is still present in Fedora 22. It happens infrequently, but I've had it happen twice in the last 2 days. The only remedy I have found is a reboot. It seems like the password entry is auto-submitting every half second or so - I can get to 4 characters of my password if I type fast before it is submitted and I see "Authentication failed" appear under the text input. I can still log in to text terminals on tty3-6, but the GNOME session on tty2 is locked, and if I try to "log in as another user", it blocks before handing off to gnome-session. I will attach the relevant logs. --- Additional comment from Jan Synacek on 2017-09-15 13:24:26 UTC --- (In reply to Dave Neary from comment #35) > I will attach the relevant logs. Don't bother. Fedora 22 has been EOL for quite some time, nobody's going to look at this. If it still happens with F25, then feel free to reopen this bugzilla. --- Additional comment from Dave Neary on 2017-09-15 13:25:20 UTC --- --- Additional comment from Dave Neary on 2017-09-15 13:43:00 UTC --- (In reply to Jan Synacek from comment #36) > (In reply to Dave Neary from comment #35) > > I will attach the relevant logs. > > Don't bother. Fedora 22 has been EOL for quite some time, nobody's going to > look at this. If it still happens with F25, then feel free to reopen this > bugzilla. I was looking at the comments in this bug - is there any indication that this issue, which clearly affected a number of people, across at least 3 Fedora releases, has been addressed by Fedora 25? Nothing in the comments indicates that this has been fixed or addressed by the systemd team. As a "Heisenbug", I have no idea what triggers it. Thanks to this bug, I did figure out how to identify a potential culprit and remediate it (FYI, "systemctl stop gdm.service && systemctl start gdm.service" cleared the failed state without killing my GNOME session and I managed to log in again from the locked screen). Leaving that behind for those who may follow after (like me, through Google search results). --- Additional comment from Jan Synacek on 2017-09-15 15:43:56 UTC --- One of the indication might be that people don't complain anymore. Many bugs get reassigned to the latest stable release if people still run into them. And since systemd gets rebased every Fedora release, I guess this issue might not appear there anymore, but I haven't tried (honestly, trying to reproduce a bug that happens "once in a blue moon" is no fun). --- Additional comment from Lars E. Pettersson on 2017-09-15 16:36:23 UTC --- I had forgotten about this bug report. These lockups, where one is not able to login from the lock screen, has happened once in a blue moon since first reported. Last time was 2-3 weeks ago (I think). So whatever the bug is, it seem to still be there. It seem to be related with leaving the machine locked for a longer period of time (during night), and often with updates being applied during that period (but not always). Next time I will try Dave Neary's stop/start gdm.service hint, and see if that helps. --- Additional comment from Brian J. Murrell on 2017-10-19 10:54:31 UTC --- Can this bug be reopened please, since it is happening on my F26 system and comment #40 even updated the Version from 20 -> 26. --- Additional comment from Brian J. Murrell on 2017-10-19 11:07:05 UTC --- When this happens to me, I don't get anything new/interesting in the journal (i.e. watching journalctl -f while trying to unlock the screen). I usually end up going back to the main GDM login screen (ctrl-alt-F1) and logging in there which brings me back to the session I left locked. I did try restarting GDM per comment #38 and while that did restart GDM and didn't kill my desktop, I couldn't find any way to get back to it other than to VNC to it. Switching to the VT that the Xserver was running on just displayed a flashing underscore-style cursor. --- Additional comment from Lars E. Pettersson on 2017-10-19 19:10:54 UTC --- Re-open the bug ticket. --- Additional comment from on 2017-12-16 23:36:48 UTC --- I have seen this also in RHEL 7.4. My screen will lock, and when I try to log back in, the password entry field and the login button will both gray out and become disabled. It almost appears that it is auto-submitting a login request. If I hit enter and type my password fast enough, I can submit my login attempt but it fails. My work arounds have had various success. I seem to hit it less often if I manually lock the computer instead of it locking automatically. Sometimes after hitting the issue, putting the computer in sleep mode will allow me to login. Sometimes I either have to wait for an extended period of time or plain out restart the computer. I hit this all the time. It is not what I would call intermittent. --- Additional comment from Daniel Zirkin on 2018-03-08 18:19:39 UTC --- I just updated to FC 27... having the same problem. I only experience it when I log into a VNC session which has been open for a while. I have to "vncserver -kill :1" and reload to get back in. It's the same symptoms of constant "enter" attempts. --- Additional comment from Troels Arvin on 2018-03-08 19:01:03 UTC --- I managed to somehow turn off the screen-saver, and then the problem has vanished. But it also means that even in normal (non-VNC) mode, my workstation's screen no longer locks automatically after a while. --- Additional comment from Daniel Zirkin on 2018-03-08 20:05:18 UTC --- I'll try it. The monitor is off. Thanks for the suggestion! --- Additional comment from Daniel Zirkin on 2018-03-09 16:46:12 UTC --- Same problem today. What logs... what information does anyone need to help trouble shoot this? I can leave it in this condition as long as it takes to finally get to the bottom of this. --- Additional comment from Daniel Zirkin on 2018-03-09 16:55:55 UTC --- From journalctl -f: ************* gnome-shell[14550]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 ************* gnome-shell[14550]: JS ERROR: TypeError: childToShow is null AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:70:13 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 AltSwitcher<._onCapturedEvent@resource:///org/gnome/shell/ui/status/system.js:97:17 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 ************* gnome-shell[14550]: JS ERROR: Exception in callback for signal: verification-failed: TypeError: this._entry.clutter_text is undefined AuthPrompt<.updateSensitivity@resource:///org/gnome/shell/gdm/authPrompt.js:421:9 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 AuthPrompt<._onVerificationFailed@resource:///org/gnome/shell/gdm/authPrompt.js:258:9 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 _emit@resource:///org/gnome/gjs/modules/signals.js:126:27 ShellUserVerifier<._verificationFailed@resource:///org/gnome/shell/gdm/util.js:563:9 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 ShellUserVerifier<._reportInitError@resource:///org/gnome/shell/gdm/util.js:347:9 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:364:13 wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 --- Additional comment from Samuel Irlapati on 2018-03-27 22:25:05 UTC --- I am on fedora 27 and this is happening for me too. Is there anything I can do to help find a fix? --- Additional comment from Daniel Zirkin on 2018-03-27 22:44:06 UTC --- I never found a solution. I have to turn off vncserver after each session. --- Additional comment from Daniel Zirkin on 2018-04-01 19:36:25 UTC --- Did another update last night... now it's working... --- Additional comment from Daniel Zirkin on 2018-04-20 13:06:24 UTC --- ... and after last update... it's back again. Now having the same problem on ver 27. logs Apr 20 08:50:33 server journal[6433]: JS ERROR: TypeError: childToShow is null#012AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:70:13#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SystemActions<._updatePowerOff@resource:///org/gnome/shell/misc/systemActions.js:335:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SystemActions<._sessionUpdated@resource:///org/gnome/shell/misc/systemActions.js:256:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SystemActions<._init/<@resource:///org/gnome/shell/misc/systemActions.js:189:53#012_emit@resource:///org/gnome/gjs/modules/signals.js:126:27#012SessionMode<._sync@resource:///org/gnome/shell/ui/sessionMode.js:204:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SessionMode<.popMode@resource:///org/gnome/shell/ui/sessionMode.js:173:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012ScreenShield<._hideLockScreenComplete@resource:///org/gnome/shell/ui/screenShield.js:922:13#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_addHandler/params[name]@resource:///org/gnome/shell/ui/tweener.js:91:13#012_callOnFunction@resource:///org/gnome/gjs/modules/tweener/tweener.js:203:13#012_updateTweenByIndex@resource:///org/gnome/gjs/modules/tweener/tweener.js:332:9#012_updateTweens@resource:///org/gnome/gjs/modules/tweener/tweener.js:345:18#012_onEnterFrame@resource:///org/gnome/gjs/modules/tweener/tweener.js:360:10#012_emit@resource:///org/gnome/gjs/modules/signals.js:126:27#012ClutterFrameTicker<._onNewFrame@resource:///org/gnome/shell/ui/tweener.js:208:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012ClutterFrameTicker<._init/<@resource:///org/gnome/shell/ui/tweener.js:183:17 Apr 20 08:50:33 server journal[6433]: JS ERROR: TypeError: childToShow is null#012AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:70:13#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SystemActions<._updateSuspend@resource:///org/gnome/shell/misc/systemActions.js:353:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SystemActions<._sessionUpdated@resource:///org/gnome/shell/misc/systemActions.js:257:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SystemActions<._init/<@resource:///org/gnome/shell/misc/systemActions.js:189:53#012_emit@resource:///org/gnome/gjs/modules/signals.js:126:27#012SessionMode<._sync@resource:///org/gnome/shell/ui/sessionMode.js:204:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012SessionMode<.popMode@resource:///org/gnome/shell/ui/sessionMode.js:173:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012ScreenShield<._hideLockScreenComplete@resource:///org/gnome/shell/ui/screenShield.js:922:13#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_addHandler/params[name]@resource:///org/gnome/shell/ui/tweener.js:91:13#012_callOnFunction@resource:///org/gnome/gjs/modules/tweener/tweener.js:203:13#012_updateTweenByIndex@resource:///org/gnome/gjs/modules/tweener/tweener.js:332:9#012_updateTweens@resource:///org/gnome/gjs/modules/tweener/tweener.js:345:18#012_onEnterFrame@resource:///org/gnome/gjs/modules/tweener/tweener.js:360:10#012_emit@resource:///org/gnome/gjs/modules/signals.js:126:27#012ClutterFrameTicker<._onNewFrame@resource:///org/gnome/shell/ui/tweener.js:208:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012ClutterFrameTicker<._init/<@resource:///org/gnome/shell/ui/tweener.js:183:17 Apr 20 08:50:33 server journal[6433]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available#012ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 Apr 20 08:50:34 server journal[6433]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available#012ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 Apr 20 08:50:35 server journal[6433]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available#012ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 --- Additional comment from Fedora End Of Life on 2018-05-03 08:19:06 UTC --- This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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. --- Additional comment from Chen Chen on 2018-05-04 02:08:57 UTC --- Changed target version, as comment #45 and #50 reproduced it on f27. --- Additional comment from Daniel Zirkin on 2018-05-10 00:37:26 UTC --- So after an system update last night... now it's working. Gonna hold off on updating to F28 since things are finally working. --- Additional comment from on 2018-06-04 04:50:16 UTC --- I have a fedora 26 pc running. I can login to the pc using ssh from laptop with fedora 28. I can start a vncserver. I can then exit ssh and connect to vncserver. vnc password is accepted. I then get a user logon required for color profile screen. I add my user password and user logon required for color profile screen appears again, and again(three times) but then I am logged in. I can start a perl programme in a terminal and then disconnect from the server without logout. I can reconnect immediately to the server and everythiong is ok, but if I wait 15 mins and then try to reconnect my vnc password is accepted, but my user login screen has already given me an authentication failure. I start to add my password but I only have time to add one character before it resets to authentication failure. I can ssh back in and check that the vncserver is still running. I can kill the vncserver. I can restart a vncserver. I can connect to the vncserver and then it breaks again after about 15 mins. This seems to be the same problem as this bug, has it been solved yet? I have also commented on ask.fedora(no answer yet). --- Additional comment from on 2018-06-25 12:10:26 UTC --- Working on F28, i have the same problem. Is there any fix available? --- Additional comment from Daniel Zirkin on 2018-06-25 14:43:55 UTC --- Who knows... started working for me magically... --- Additional comment from on 2018-06-25 15:05:01 UTC --- @Daniel Thanks for that comment. Really helpful... not. Workaround for me: replace the xinitrc call in xstartup with e.g. exec mate-session, so that gdm is not involved. i also switched to lightdm --- Additional comment from on 2018-06-26 04:26:20 UTC --- Has been working for me since my last post without changing anything. I am waiting for it to break again!! --- Additional comment from on 2018-06-28 05:52:20 UTC --- Hi. I had to shut down PC due to a power outage which I then restarted. I logged in from laptop via ssh and started vncserver. Connected to vncserver. Vncpassword accepted. User password accepted. Disconnected from vncserver and waited 15 mins. Tried to connect again. Vncpassword accepted. Won't let me add user password. Kill vncserver and restart. Login again and all OK. Wait until screen lock happens (15 mins) before disconnecting. Try reconnecting and all OK. Don't know if this gives anyone a clue as to what is happening. Waiting for it to break again! --- Additional comment from on 2018-06-30 03:28:58 UTC --- Slight difference. vncpassword accepted but can't access user login screen. ssh shows vnc server running. kill. restart. still the same. kill. restart. connects ok. disconnect immediately. reconnect immediately. still ok. wait for lock. back to won't let me add password. kill. restart. ok. wait for lock. disconnect. reconnects ok. waiting for it to break again. --- Additional comment from on 2018-06-30 04:28:17 UTC --- Already broken. Trying mate-session. so far so good. waiting for it to break. --- Additional comment from on 2018-07-04 07:36:02 UTC --- Still working even after reboots. Seems like this is a gdm or gnome problem. Any gdm/gnome experts on this bug list?? I don't consider this bug solved, but at least I don't keep losing info. thanks @oliver. --- Additional comment from Andrey Arapov on 2018-07-08 07:54:55 UTC --- I am actually having exactly the same issue as OP, once a "blue moon" (sometimes). Similarly to Cyril Bouteille I have been able to return back to my user session without losing open programs by restarting gnome-shell from another console (Ctrl+Alt+F3) and returning back to the graphical session (Ctrl+Alt+F2 in my case or you could browse through by pressing Ctrl+Alt+Left or Right arrows) Then, each time I lock my session, it would not let me enter the password on login prompt again, i.e. after typing few letters to the password prompt box, it would just erase those.. and if I managed quickly typing my very short password, it would still not allow me in. Then, I would just switch to GDM (Ctrl+Alt+F1) which would allow me login back to my session without losing the open programs. Finally, after looking at ``man gnome-shell``, I have noticed the ``--mode=user`` argument, which would fix the issue. Now the password can be entered and it would just work :-) (Ctrl+Alt+F3, logged under my user) ``` export DISPLAY=:0 nohup gnome-shell --mode=user --replace & exit ``` Maybe this will save someone a headache :-) -- P.S. the difference is that I am using Ubuntu 18.04 Bionic with gnome-shell 3.28.1-0ubuntu2, but I think it is the same, gnome shell related problem. --- Additional comment from on 2018-07-09 05:07:44 UTC --- Can this be done over ssh? --- Additional comment from Tony on 2018-07-09 20:40:50 UTC --- I was unable to remotely login to my CentOS 7 (Linux 3.10.0-862.6.3.el7.x86_64) desktop, because my password was erased as I typed it. Disabling the CentOS screenlock and rebooting CentOS worked for me. My environment is as follows: - CentOS 7 with TigerVNCServer running in Hyper-V 2016 VM - Clients that exhibited this behavior are TightVNC 2.8.11 (Windows) and VNCViewer 6.17.1113 (Windows and OSX Sierra) Prior to disabling CentOS screenlock, my password would be "erased" as I was typing it. --- Additional comment from RobbieTheK on 2018-07-19 22:41:05 UTC --- We started seeing that password field flicker effect today after seeing these dnf error with soundtouch: Problem: package gstreamer1-plugins-bad-free-1.12.4-1.fc27.x8664 requires libSoundTouch.so.1()(64bit), but none of the providers can be installed - cannot install both soundtouch-2.0.0-3.fc27.x8664 and soundtouch-1.9.2-6.fc27.x8664 - cannot install both soundtouch-1.9.2-6.fc27.x8664 and soundtouch-2.0.0-3.fc27.x8664 - cannot install the best update candidate for package soundtouch-1.9.2-6.fc27.x8664 cannot install the best update candidate for package gstreamer1-plugins-bad-free-1.12.4-1.fc27.x86_64 ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): soundtouch x86_64 2.0.0-3.fc27 updates 72 k If you run def update sound tech --best --allowerasing you will end up breaking GDM and will see these errors: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.DisplayManager was not provided by any .service files #012ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34 #012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22 I then had to reinstall/re-enable/start GDM. Pretty much what is mentioned here: https://ask.fedoraproject.org/en/question/124091/f27-no-sound-after-updates/ --- Additional comment from Ben Cotton on 2018-11-27 14:57:09 UTC --- This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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. --- Additional comment from Ben Cotton on 2018-11-30 22:13:38 UTC --- Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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. --- Additional comment from Matt Heck on 2019-06-08 00:24:12 UTC --- Please see: https://bugzilla.redhat.com/show_bug.cgi?id=1534873 ...the short version is, if you see this, try uninstalling "fprintd", the fingerprint reader daemon. --- Additional comment from on 2019-10-05 00:25:42 UTC --- I am seeing this broken behaviour on RHEL8. I do not have fprintd installed Steps to reproduce - Connect to server using tigervnc client - wait for screen lock - try to enter password [root@cheops rlogie]# yum list|grep vnc gtk-vnc2.x86_64 0.9.0-1.el8 @AppStream gvnc.x86_64 0.9.0-1.el8 @AppStream tigervnc-license.noarch 1.9.0-9.el8 @rhel-8-for-x86_64-appstream-rpms tigervnc-server.x86_64 1.9.0-9.el8 @rhel-8-for-x86_64-appstream-rpms tigervnc-server-minimal.x86_64 1.9.0-9.el8 @rhel-8-for-x86_64-appstream-rpms gtk-vnc2.i686 0.9.0-1.el8 rhel-8-for-x86_64-appstream-rpms gvnc.i686 0.9.0-1.el8 rhel-8-for-x86_64-appstream-rpms libvncserver.i686 0.9.11-9.el8 rhel-8-for-x86_64-appstream-rpms libvncserver.x86_64 0.9.11-9.el8 rhel-8-for-x86_64-appstream-rpms tigervnc.x86_64 1.9.0-9.el8 rhel-8-for-x86_64-appstream-rpms tigervnc-icons.noarch 1.9.0-9.el8 rhel-8-for-x86_64-appstream-rpms tigervnc-server-applet.noarch 1.9.0-9.el8 rhel-8-for-x86_64-appstream-rpms tigervnc-server-module.x86_64 1.9.0-9.el8 rhel-8-for-x86_64-appstream-rpms --- Additional comment from Daniel Zirkin on 2019-11-08 02:47:53 UTC --- Update to FC 31 now... back again!
Please don't clone bugs. Bugzilla offers that, but has toomany downsides. With a F27-era bug with a hundred subscribers, it spams all of them. It is unlikely to be the same issue, even if the symptoms are similar. And if it was the same issue, it'd be better to reopen an old bug. Also, you didn't provide any details that must be always attached to a bug: versions, logs, symptoms.
FC31 gnome-shell 3.34.1-4 All was good; dnf update... problem re-appeared. Multiple reboots later... same effect. Using nxserver to remote access. If I lock the screen or auto-lock via privacy settings, when I try to log back in it appears that a phantom enter key is being pressed constantly. Kill gnome-shell... wait for it to restart and all is good.
Example video https://youtu.be/NQ6S8VeoKd0
I changed to mate terminal. Fixed my problem but not the underlying problem.
I finally caught something on Journalctl; Dec 23 23:58:57 computer.computer gnome-shell[1855202]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available _reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:345:34 I'm really not sure where to go with this...
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.