Bug 912892

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.

Sorry, ignore the previous comment, it's failed again.

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.

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.

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)

hth,
-brian

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: 10.1.176.6::58823
 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?

Same problem here.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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

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.

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.

I'm having the same problem with TigerVNC, but from Fedora 19.

Also see bug 960149, which also has a reference to an upstream report.

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.

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

I'm in Fedora 20 and I get this behavior.  Is there any workaround?

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

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

"Me too"  Comment 10 works great, though.  If I can provide any logging or help test anything, I'd be very happy to.

I got it working by making /etc/pam_ldap.conf world readable.

# chmod 644 /etc/pam_ldap.conf

I'm also seeing this problem in F20.  Very annoying.

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.

Created attachment 920535 [details]
journalctl -af

For comment 23.

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.

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