Bug 912892 - Cannot unlock screen when connected using tigervnc-server
Summary: Cannot unlock screen when connected using tigervnc-server
Status: CLOSED DUPLICATE of bug 960149
Alias: None
Product: Fedora
Classification: Fedora
Component: tigervnc
Version: 20
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-02-19 22:51 UTC by L.L.Robinson
Modified: 2014-07-24 14:11 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-07-24 14:11:08 UTC
Type: Bug

Attachments (Terms of Use)
journalctl -af (8.89 KB, text/plain)
2014-07-24 13:25 UTC, llarevo
no flags Details

Description L.L.Robinson 2013-02-19 22:51:11 UTC
Description of problem:

If you configure to connect your machine via tigervnc-server and configure it as per this bug status https://bugzilla.redhat.com/show_bug.cgi?id=896648 then lock the screen you cannot unlock it.

Version-Release number of selected component (if applicable):

1.2.80 - 0.8.20130124svn5036.fc18

How reproducible:

Steps to Reproduce:
1. Install tigervnc-server
2. configure as per documentation and bug report https://bugzilla.redhat.com/show_bug.cgi?id=896648
3. connect using tigervnc-viewer (vncviewer)
4. Lock Screen
5. dismiss lock screen blind (mouse drag up or ESC key) and enter password 
Actual results:
Screen does not unlock

Expected results:
Screen to unlock and return to desktop

Additional info:

Service output
root@localhost ~]# systemctl status vncserver@:2.service
vncserver@:2.service - Remote desktop service (VNC)
          Loaded: loaded (/etc/systemd/system/vncserver@:2.service; enabled)
          Active: failed (Result: exit-code) since Tue 2013-02-19 22:44:33 GMT; 2min 12s ago
         Process: 1017 ExecStart=/sbin/runuser -l baggypants -c /usr/bin/vncserver -fg %i (code=exited, status=1/FAILURE)
         Process: 986 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)

Feb 19 22:43:00 localhost.clarkconnect.lan systemd[1]: Starting Remote desktop service (VNC)...
Feb 19 22:43:06 localhost.clarkconnect.lan runuser[1017]: New 'localhost.clarkconnect.lan:2 (baggypants)' ...n:2
Feb 19 22:43:06 localhost.clarkconnect.lan runuser[1017]: Starting applications specified in /home/baggypa...tup
Feb 19 22:43:06 localhost.clarkconnect.lan runuser[1017]: Log file is /home/baggypants/.vnc/localhost.clar...log
Feb 19 22:44:31 localhost.clarkconnect.lan systemd[1]: vncserver@:2.service operation timed out. Terminating.
Feb 19 22:44:33 localhost.clarkconnect.lan runuser[1017]: Session terminated, killing shell... ...killed.
Feb 19 22:44:33 localhost.clarkconnect.lan systemd[1]: vncserver@:2.service: control process exited, code=...s=1
Feb 19 22:44:33 localhost.clarkconnect.lan systemd[1]: Failed to start Remote desktop service (VNC).
Feb 19 22:44:33 localhost.clarkconnect.lan systemd[1]: Unit vncserver@:2.service entered failed state

Comment 1 L.L.Robinson 2013-02-19 22:59:47 UTC
Ignore the service output, It seems that's because I forgot to uncomment the line Exestop in the service file, the service is not failing now.

Comment 2 L.L.Robinson 2013-02-19 23:00:30 UTC
Sorry, ignore the previous comment, it's failed again.

Comment 3 Adam Tkac 2013-02-20 09:16:00 UTC
Can you please verify that steps written in https://bugzilla.redhat.com/show_bug.cgi?id=896648#c15 doesn't help? Because from service output it seems you tried to modify pam.d/runuser-l file and vncserver.service file.

Comment 4 L.L.Robinson 2013-02-21 20:42:49 UTC
The steps in bug 896648 mean I can actually connect and use the vncserver wheras before I couldn't. However It doesn't help the lockscreen issue. I have modified the pam.d/runuser-l and vncserver@:<num>.service file as per the bug.

Comment 5 Brian Hinz 2013-02-26 21:12:37 UTC
This looks like it might be due to gnome-screensaver not playing nice with the sepermit PAM module.  If I comment out the first auth line in /etc/pam.d/gnome-screensaver, then the screen lock feature works just fine.  On EL6 this line looks like:

auth     [success=done ignore default=bad] pam_selinux_permit.so

Note that I have SElinux disabled, which implies that sepermit should return PAM_IGNORE.  I see the following in /var/log/messages:

WARN <fd:26 gnome-screensav(26117)> client.gnome-screensav Unexpected error in conversation: (19)


Comment 6 Easior Lars 2013-04-29 07:33:00 UTC
I have also suffered from this problem. If I made VNC setup with initial configuration, then I could login Gnome 3 on Fedora 18 by VNC. After I quitted from remote machine and gnome-screensaver was taken action, I couldn't login that remote machine by VNC. By ssh, I found the following log in ~/.vnc/localhost.localdomain\:1.log in that remote host:

Mon Apr 29 15:12:25 2013
 Connections: accepted:
 SConnection: Client needs protocol version 3.8
 SConnection: Client requests security type VncAuth(2)

Mon Apr 29 15:12:29 2013
 VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian rgb888
 VNCSConnST:  Client pixel format depth 8 (8bpp) color-map

(gnome-settings-daemon:23370): power-plugin-WARNING **: failed to turn the panel on: Display is not DPMS capable
    JS ERROR: !!!   Exception was: TypeError: Object 0x9e8a04d0 is not a subclass of (null), it's a GLib_Error
    JS ERROR: !!!     message = '"Object 0x9e8a04d0 is not a subclass of (null), it's a GLib_Error"'
    JS ERROR: !!!     fileName = '"/usr/share/gnome-shell/js/gdm/util.js"'
    JS ERROR: !!!     lineNumber = '159'
    JS ERROR: !!!     stack = '"([object _private_Gdm_Client],[object _private_Gio_SimpleAsyncResult])@/usr/share/gnome-shell/js/gdm/util.js:159
wrapper([object _private_Gdm_Client],[object _private_Gio_SimpleAsyncResult])@/usr/share/gjs-1.0/lang.js:204

Any hint?

If I try to restart vncserver by

$ vncserver -kill :1
$ vncserver :1

then remote VNC server works well before another gnome-screensaver start.

I also googled on internet. I found that there are some comments about this problem. They said that, if you switch xfce from gnome3, then VNC will work properly. Anyone agree with that?

Comment 8 Cheng Guangn-Nan 2013-05-06 08:41:16 UTC
Same problem here.

Comment 9 Fedora Admin XMLRPC Client 2013-05-13 14:54:28 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 TomW 2013-07-12 17:12:58 UTC
I have been using loginctl as a workaround to this issue. Obviously you must have root on the system.

loginctl list-sessions
loginctl unlock-session $session

Comment 11 John Hein 2013-07-18 22:53:28 UTC
I have the same general problem (can't unlock a screen lock in a vnc session on F18).

I see no gnome-screensaver running and commenting the auth line in /etc/pam.d/gnome-screensaver doesn't help (cf. comment 5).

'loginctl unlock-sessions' or 'loginctl unlock-session $session' for any of the listed sessions doesn't unlock the vnc session (cf. comment 10).

Note that I manually started vncserver from the command line, not as a service as described in bug 896648 (mentioned in comment 3 - comment 4).

I do see similar messages in .vnc/localhost.localdomain:1.log as the ones shown in comment 7.

What _does_ work around the problem for me is killing gnome-shell, then starting gnome-shell manually at the command line of a gnome-terminal that was already running in that vnc session (and so has the right DBUS* env vars set allowing the new gnome-shell to connect to the dbus session properly).

Turning off 'Lock' in the System Settings->Brightness & Lock gui works around this problem, too.  But that setting would affect non-vnc sessions as well.

Comment 12 Jim Hogarth 2013-09-05 13:05:00 UTC
I'm having the same problem with TigerVNC, but from Fedora 19.

My workaround is to kill and restart the VNC session from a SSH terminal connected to the install.

Comment 13 Kurt Miller 2013-09-13 18:36:26 UTC
I'm having the same problem with TigerVNC, but from Fedora 19.

Comment 14 Pierre Ossman 2013-09-24 08:56:44 UTC
Also see bug 960149, which also has a reference to an upstream report.

Comment 15 Fedora End Of Life 2013-12-21 11:32:51 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 
'version' of '18'.

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 prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 to Fedora 18's end of life.

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 16 L.L.Robinson 2013-12-21 21:02:03 UTC
I've updated to Fedora 19 as people have commented they are still having issues. I've also briefly tested this issue and found it impacts the rhel 7 beta

Comment 17 Jorge Fábregas 2014-01-09 14:38:17 UTC
I'm in Fedora 20 and I get this behavior.  Is there any workaround?

Comment 18 Vaughan Cao 2014-01-25 05:12:07 UTC
(In reply to Jorge Fábregas from comment #17)
> I'm in Fedora 20 and I get this behavior.  Is there any workaround?

commit 10 is the workaround I prefer.

Comment 19 Vaughan Cao 2014-01-25 05:13:50 UTC
(In reply to Jorge Fábregas from comment #17)
> I'm in Fedora 20 and I get this behavior.  Is there any workaround?

Comment 10 is the workaround I prefer.

Comment 20 Jason Elwell 2014-05-10 15:54:00 UTC
"Me too"  Comment 10 works great, though.  If I can provide any logging or help test anything, I'd be very happy to.

Comment 21 Richard 2014-06-03 09:54:36 UTC
I got it working by making /etc/pam_ldap.conf world readable.

# chmod 644 /etc/pam_ldap.conf

Comment 22 Richard Keech 2014-07-02 06:09:08 UTC
I'm also seeing this problem in F20.  Very annoying.

Comment 23 llarevo 2014-07-24 13:23:20 UTC
According to https://bugzilla.redhat.com/show_bug.cgi?id=1112982#c22 I repost my bugreport regarding the unlock-issue when working with x0vncserver/vinagre here:

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.

This error occurs when usin a F20 upgraded from F19 via fedup as well as on a fresh installed F20.

Comment 24 llarevo 2014-07-24 13:25:14 UTC
Created attachment 920535 [details]
journalctl -af

For comment 23.

Comment 25 llarevo 2014-07-24 13:44:34 UTC
Steps in comment 3 doesn't work
Steps in comment 10 do work
comment 21 doesn't apply, because on my installation no /etc/pam_ldap.conf exists.

Comment 26 Tim Waugh 2014-07-24 14:11:08 UTC

*** This bug has been marked as a duplicate of bug 960149 ***

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