Bug 1098740

This a clone report, the original bug is apparently not resolved. The system is fc20 with all updates installed. The symtems are the same as reported in this thread. 

below are the versions reported based on the original input:

rpm -qa |grep tigervnc-server
tigervnc-server-1.3.0-14.fc20.x86_64

rpm -qa |grep systemd-2
systemd-208-16.fc20.x86_64

systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:3.service; enabled)
   Active: active (running) since Sat 2014-05-17 13:30:00 PDT; 13min ago
  Process: 22923 ExecStart=/sbin/runuser -l guest -c /usr/bin/vncserver %i (code=exited, status=0/SUCCESS)
  Process: 22920 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 22950 (Xvnc)
   CGroup: /system.slice/system-vncserver.slice/vncserver@:3.service
           \u2023 22950 /usr/bin/Xvnc :3 -desktop dbserver:3 (guest) -httpd /usr/share/vnc/c...

May 17 13:30:00 dbserver systemd[1]: Started Remote desktop service (VNC).


the following error message appears about 3 times per second in the message file:

May 17 13:32:59 dbserver gnome-session: (gnome-shell:23148): Gjs-WARNING **: JS ERROR: Failed to open reauthentication channel: [boxed instance proxy GIName:GLib.Error jsobj@0x7fe90ffa87c0 native@0x57abcb0]

Please let me know if additional information is needed. This was done on a clean fc20 install. It was tested on two separate user accounts. Multiple options for configuring 

************************************************************************
Original report below
************************************************************************

+++ This bug was initially created as a clone of Bug #1002464 +++

Installation of Fedora 20 TC2 (netinstall) in qemu using:

    ionice -c 3 qemu-kvm -enable-kvm -m 2048M -smp 4 -drive file=./Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2-output.log -name Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2 -cdrom /local/mfabian/iso/Fedora-20-Alpha-TC2/Fedora-20-Alpha-TC2-x86_64-netinst.iso -boot c -spice port=6000,disable-ticketing -vga cirrus -display vnc=:4 -net nic -net user,hostname=Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2,hostfwd=tcp::5556-:22 -monitor stdio -usb

- Installation in Japanese
- everything else default
- in gnome-initial-setup, I removed the non-existing "anthy"
  input method and added "Kanji Kana" (kkc), everything else
  default
- after first login into gnome, type ESC to close the introduction
  video
- close browser
- open a gnome-terminal
- lock the screen by using the menu item at the top right
  (see attached video) or wait until the lock screen starts
  automaticall (behaviour is the same)

Now the lock screen cannot be unlocked anymore.

It flickers and says "Authentication failure" all the time
(認証エラー). One cannot type more than one letter into the
password entry field, then it is apparently already tested
as a password, which fails. As if something hits the "Unlock" button
or presses the ENTER key automatically.

--- Additional comment from Flóki Pálsson on 2013-08-29 19:32:24 EDT ---

This is also on bare metal. 
Ctrl + Allt + F2
and 
Ctrl + Allt + F1
helps

--- Additional comment from Petr Schindler on 2013-09-04 07:24:46 EDT ---



--- Additional comment from Petr Schindler on 2013-09-04 07:25:20 EDT ---

This happens after boot before another session is started.

Reproducer:
1. boot f20 gnome and log in
2. lock the screen
3. try to unlock

It tries to authenticate the user and fails. If another session is open (for example some virtual console) it start to work fine.

You can find output of journalctl -a in comment 2

--- Additional comment from Dethlef Madsen on 2013-09-05 14:42:25 EDT ---


ack: tested with Fedora-Live-Desktop-i686-20-Alpha-TC4.iso 05-Sep-2013 03:51

real hardware, no VM

ctrl+alt+f2 and ctrl+alt+f1 still helps

--- Additional comment from Michele Baldessari on 2013-09-08 06:49:56 EDT ---

If the login state for the user is in "closing" then it is probably:
https://bugs.freedesktop.org/show_bug.cgi?id=67273

So we'd need the following in systemd:
commit 76e665855edef5b7103cb09d114377d477bfae02
Author: Lennart Poettering <lennart>
Date:   Fri Jul 26 18:59:46 2013 +0200

    logind: update the session state file before we send out the CreateSession() reply
    
    https://bugs.freedesktop.org/show_bug.cgi?id=67273

--- Additional comment from Fedora Update System on 2013-09-09 06:46:08 EDT ---

systemd-206-11.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-206-11.fc20

--- Additional comment from Fedora Update System on 2013-09-09 12:22:52 EDT ---

Package systemd-206-11.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-206-11.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-16167/systemd-206-11.fc20
then log in and leave karma (feedback).

--- Additional comment from Kamil Páral on 2013-09-09 12:49:25 EDT ---

Discussed at 2013-09-09 blocker review meeting [1]. This was rejected as a blocker and accepted as a freeze exception for Alpha. While this doesn't violate any of the F20 alpha release criterion, it is a rather ugly problem that's easy to hit. A tested fix would be considered past freeze.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-09/

--- Additional comment from Robert Lightfoot on 2013-09-09 15:57:11 EDT ---

systemd-206.11 resolves this bug, but as of 9/9/2013 had not propagated to the mirrors.  I had to direct download it from koji.

--- Additional comment from Kamil Páral on 2013-09-10 04:36:50 EDT ---

When I updated to systemd-206.11 the unlock screen started to work correctly. No other issues seen.

--- Additional comment from Martin Krizek on 2013-09-10 04:47:56 EDT ---

Confirming that systemd-206.11 fixes the issue.

--- Additional comment from Parag on 2013-09-11 01:04:04 EDT ---

confirm this finally fixed the gnome screen lock.

--- Additional comment from Fedora Update System on 2013-09-13 23:09:07 EDT ---

systemd-206-11.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from  on 2013-12-28 18:01:39 EST ---

I am experiencing the identical problem with the "general availability" Fedora 20 installed from Live Media on real hardware (not a VM). Arch: x86_64. No modifications, except I added packages tigervnc, tigervnc-server, emacs, wget from yum. Movie from original post shows exactly what I am seeing, except my UI is English. Following the discussion above, I have systemd 208.9.fc20. Can no longer install 206.11 since the updates-testing repo also has 208.9.fc20. The ctl+alt+f2 and ctrl+alt+f1 work-arounds described above do not work for me.

--- Additional comment from Mark C. Edwards on 2013-12-28 23:37:16 EST ---

Confirming the problem on the f20 x86_64 (real hardware). Update applied 12-28 caused the lock screen authentication to fail on two different x86_64 machines. The ctl-alt-f2 fails. Was able to login as root and shutdown.
systemd-libs-208-9.fc20.x86_64, systemd-208-9.fc20.x86_64
is the installed version.

--- Additional comment from Brad Smith on 2013-12-31 18:09:48 EST ---

I just updated to F20 from F19 using fedup. If I lock the desktop, I cannot unlock.

systemd-208-9.fc20.x86_64

--- Additional comment from Brad Smith on 2014-01-01 11:17:16 EST ---

(In reply to Brad Smith from comment #16)
> I just updated to F20 from F19 using fedup. If I lock the desktop, I cannot
> unlock.
> 
> systemd-208-9.fc20.x86_64

I have to retract this assertion. Screen unlock started to work. The only change made to the system other than normal yum updates was the deletion of virtually all systemd journal files from FC19.

--- Additional comment from  on 2014-01-10 10:08:18 EST ---

I cannot unlock either 

      systemd-208-9.fc20.x86_64

I am not sure as to why the bug has been changed to CLOSED ERRATA. The bug is UNSOLVED! There is no fix/update provided by F20.

--- Additional comment from  on 2014-01-11 15:09:32 EST ---

I ran sudo yum update today and saw package names that might bear on this problem. After completing the update, I rebooted -- not sure if that was needed -- and verified the problem is resolved for me. Here are the updates that I think did it:

Jan 11 10:12:37 Updated: 1:NetworkManager-openvpn-0.9.8.2-4fc20.x86_64
Jan 11 10:12:50 Updated: 1:NetworkManager-openvpn-gnome-0.9.8.2-4fc20.x86_64

--- Additional comment from Dario Izzo on 2014-01-24 04:36:16 EST ---

I made a fresh install of fedora 20 (x86_64), then I installed 

sudo yum -y install tigervnc-server
vncpasswd
Password:# input
Verify:# confirm

vncserver :4 -geometry 1024x768 -depth 24
sudo systemctl stop firewalld.service (this is not ideal but just to make my point)

From my windows machine I then use togherVN (or ultraVNC) to connect to the screen. If locked I cannot login as the unlock button seems to be pressed automatically several time a second (so I do not have time to enter the password)

This seems to be the same bug here reported and it does not look as its solved.

--- Additional comment from  on 2014-04-27 12:53:18 EDT ---

I also can not unlock my desktop, until find blog with workaround.
http://blog.mornati.net/fedora-18-cant-unlock-the-screen/

When i add "fs.inotify.max_user_watches=100000" into /etc/sysctl.d/inotify.conf my problem go away.

This is the kernel parameter, perhaps gdm or systemctl watches more than 8192 files (this is default value).

--- Additional comment from Eric on 2014-05-09 10:45:39 EDT ---

I also can not unlock my gnome-session. I am VNCing into a fully updated Fedora 20 box, running a vnc server on a virtual display, :1. The symptoms are exactly the same as described before.

I can however vnc onto my :0 display and unlock it, but it seems to be using a different UI than what spawns with vncserver. But let me be clear, I am still using gnome shell with vncserver:1.