Bug 896648

Summary: vncserver fails to load gnome 3 session
Product: [Fedora] Fedora Reporter: Chris Plummer <christopher.plummer>
Component: tigervncAssignee: Jan Grulich <jgrulich>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 22CC: andrew.kavalov, aschorr, asrv01, astrand, bkelly, bobgus, bphinz, CarlHinton, dlbprocyon, fgozalo0, gtreanto, jcmj, j.mark.brooks, john.a, jonathan.underwood, jth, junk, kappaxd123, Leon, maurizio.antillon, mbradfor42, ossman, ovasik, paddy667, pierre-bugzilla, ptsprague, pwouters, rts549, sidney, steve, tekunix, twaugh, vicsperry, v.ronnen, yselkowi
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 14:50:33 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 912778, 959941    
Bug Blocks:    
Attachments:
Description Flags
The VNC log file
none
See comment 42 - this is first screenshot
none
See comment 42 - this is second screenshot
none
Successful entry during 'no password' time window - shows TWO VNC config windows
none
Screen shot showing dconf-editor with remote-access settings used. none

Description Chris Plummer 2013-01-17 11:49:42 EST
Created attachment 680372 [details]
The VNC log file

Description of problem:

I run tigervnc vncserver as a systemd service in Fedora 18.  I've run it in Fedora 17 this way with no problems, but when I connect to it in F18, the screen is blank and immediately shows a Gnome error - "Oh no! Something has gone wrong.  A problem has occurred and the system can't recover. All extensions have been disabled as a precaution."  There is a Log Out button that I press.  I am then presented with my desktop background, but no ability to do anything - docky doesn't start and pressing the windows key (or any other key) has no effect.  

The window for VNC options is visible in the upper left (it has three checkboxes, "Accept clipboard from viewers", "Send clipboard to viewers", and "Send primary selection to viewers").

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

tigervnc-server.x86_64 1.2.80-0.6.20121126svn5015.fc18

How reproducible:

Always.

Steps to Reproduce:
1. Create a vncserver configuration:

sudo cp /lib/systemd/system/vncserver@.service /etc/systemd/system/multi-user.target.wants/vncserver@:1.service

2. Edit the vncserver@:1.service file as root, replacing <USER> with your username (not root).  On the line that says 'ExecStart', add the '-geometry 1280x720' option after the '%i', within the quotations. Save the file.
3. In a terminal with your user, not root, run vncpasswd and set the VNC login password for your user.
4. Run 'sudo systemctl start vncserver@:1.service'
5. Connect to the vncserver with an external vnc client - I'm using RealVnc on my Windows 7 laptop.
  
Actual results:

The error screen mentioned above, with the Log Out button.  Press the button and the desktop comes up with no way to do anything.

Expected results:

A fully functional Gnome 3 desktop.

Additional info:

I've found a similar issue on the ArchLinux forums, but no advice yet:
https://bbs.archlinux.org/viewtopic.php?pid=1214237

I'll attach the vnc log file to the bug; here's the service file:

# The vncserver service unit file
#
# Quick HowTo:
# 1. Copy this file to /etc/systemd/system/vncserver@:<display>.service
# 2. Edit <USER> and vncserver parameters appropriately
#   ("runuser -l <USER> -c /usr/bin/vncserver %i -arg1 -arg2")
# 3. Run `systemctl daemon-reload`
# 4. Run `systemctl enable vncserver@:<display>.service`
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, you should
# limit connections to the local host and then tunnel from
# the machine you want to view VNC on (host A) to the machine
# whose VNC output you want to view (host B)
#
# [user@hostA ~]$ ssh -v -C -L 590N:localhost:590M hostB
#
# this will open a connection on port 590N of your hostA to hostB's port 590M
# (in fact, it ssh-connects to hostB and then connects to localhost (on hostB).
# See the ssh man page for details on port forwarding)
#
# You can then point a VNC client on hostA at vncdisplay N of localhost and with
# the help of ssh, you end up seeing what hostB makes available on port 590M
#
# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.
#
# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.


[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=forking
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l cplummer -c "/usr/bin/vncserver %i -geometry 1280x720"
ExecStop=/sbin/runuser -l cplummer -c "/usr/bin/vncserver -kill %i"

[Install]
WantedBy=multi-user.target
Comment 1 NM 2013-01-23 14:59:59 EST
Me too observe similar behaviour on 
Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
running Fedora Release 18 (Spherical Cow) 64-bit and gnome shell GNOME 3.6.2. The desktop GUI is cinnamon. 

After the crash the 'systemctl status vncserver@:1' reports among other thinks:
 
Jan 23 14:18:37 armat1.home systemd[1]: Started Remote desktop service (VNC).
Jan 23 14:18:37 armat1.home gnome-session[27992]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
Jan 23 14:18:37 armat1.home pulseaudio[28157]: [pulseaudio] pid.c: Daemon already running.
Jan 23 14:18:39 armat1.home goa[28303]: goa-daemon version 3.6.2 starting [main.c:112, main()]
Jan 23 14:18:39 armat1.home gnome-session[27992]: WARNING: Detected that screensaver has left the bus
Jan 23 14:18:40 armat1.home gnome-session[27992]: WARNING: App 'gnome-shell.desktop' respawning too quickly
Jan 23 14:18:40 armat1.home gnome-session[27992]: WARNING: Detected that screensaver has left the bus
Jan 23 14:21:22 armat1.home gnome-session[27992]: CRITICAL: gsm_manager_set_phase: assertion `GSM_IS_MANAGER (manager)' failed
Jan 23 14:21:22 armat1.home gnome-session[27992]: Gtk-CRITICAL: gtk_main_quit: assertion `main_loops != NULL' failed


Looks like the 'CRITICAL' lines are causing the problem. Any idea?
Comment 2 Kaloyan Mehandzhiyski 2013-01-31 06:42:18 EST
Hello, 

Same issue here:

[root@localhost ~]# systemctl status vncserver@:1.service
vncserver@:1.service - Remote desktop service (VNC)
	  Loaded: loaded (/usr/lib/systemd/system/vncserver@:1.service; enabled)
	  Active: active (running) since Thu 2013-01-31 13:30:56 EET; 11s ago
	 Process: 2433 ExecStop=/sbin/runuser -l k_georgiev -c /usr/bin/vncserver -kill %i (code=exited, status=0/SUCCESS)
	 Process: 2479 ExecStart=/sbin/runuser -l k_georgiev -c /usr/bin/vncserver %i (code=exited, status=0/SUCCESS)
	 Process: 2475 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/vncserver@.service/:1
		  ├─2500 /usr/bin/Xvnc :1 -desktop localhost.localdomain:1 (k_georgiev) -auth /home/k_georgiev/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/k_georgi...
		  ├─2507 /bin/gnome-session
		  ├─2515 dbus-launch --sh-syntax --exit-with-session
		  ├─2516 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
		  ├─2524 /usr/bin/ssh-agent /etc/X11/xinit/Xclients
		  ├─2528 /usr/libexec/at-spi-bus-launcher
		  ├─2532 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
		  ├─2536 /usr/libexec/at-spi2-registryd --use-gnome-session
		  ├─2546 /usr/bin/gnome-keyring-daemon --start --components=pkcs11
		  ├─2555 /usr/libexec/gnome-settings-daemon
		  ├─2569 /usr/libexec/gvfsd
		  ├─2573 /usr/libexec//gvfsd-fuse -f /home/k_georgiev/.gvfs
		  ├─2581 /usr/libexec/gvfs-udisks2-volume-monitor
		  ├─2585 /usr/libexec/gvfs-gphoto2-volume-monitor
		  ├─2589 /usr/libexec/gvfs-afc-volume-monitor
		  ├─2595 /usr/libexec/gsd-printer
		  ├─2604 /usr/libexec/tracker-miner-fs
		  ├─2605 /usr/libexec/tracker-store
		  ├─2611 clipit
		  ├─2618 /usr/libexec/vino-server
		  ├─2622 nautilus -n
		  ├─2623 abrt-applet
		  ├─2624 /usr/bin/seapplet
		  ├─2625 nm-applet
		  ├─2630 /usr/libexec/deja-dup/deja-dup-monitor
		  ├─2631 /usr/libexec/evolution/3.6/evolution-alarm-notify
		  ├─2638 /usr/libexec/dconf-service
		  ├─2655 /usr/libexec/gvfsd-trash --spawner :1.10 /org/gtk/gvfs/exec_spaw/0
		  ├─2661 /usr/libexec/gconfd-2
		  ├─2665 /usr/libexec/evolution-source-registry
		  ├─2672 /usr/libexec/goa-daemon
		  ├─2674 /usr/libexec/evolution-calendar-factory
		  ├─2699 /usr/libexec/gnome-shell-calendar-server
		  ├─2705 /usr/libexec/gvfsd-burn --spawner :1.10 /org/gtk/gvfs/exec_spaw/1
		  ├─2718 /usr/lib64/tumbler-1/tumblerd
		  └─2724 /usr/libexec/mission-control-5

Jan 31 13:30:56 localhost.localdomain runuser[2479]: pam_unix(runuser-l:session): session closed for user k_georgiev
Jan 31 13:30:56 localhost.localdomain systemd[1]: Started Remote desktop service (VNC).
Jan 31 13:30:56 localhost.localdomain gnome-session[2507]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getti... at login.
Jan 31 13:30:56 localhost.localdomain spice-vdagent[2543]: Missing virtio device '/dev/virtio-ports/com.redhat.spice.0': No such file or directory
Jan 31 13:30:56 localhost.localdomain pulseaudio[2560]: [pulseaudio] pid.c: Daemon already running.
Jan 31 13:30:57 localhost.localdomain gnome-session[2507]: WARNING: Failed to start app: Unable to start application: Failed to execute child process "/home/k_georgiev/sc...directory)
Jan 31 13:30:59 localhost.localdomain goa[2672]: goa-daemon version 3.6.2 starting [main.c:112, main()]
Jan 31 13:31:00 localhost.localdomain gnome-session[2507]: WARNING: Detected that screensaver has left the bus
Jan 31 13:31:01 localhost.localdomain abrt[2619]: detected unhandled Python exception in '/bin/fedmsg-notify-daemon'
Jan 31 13:31:01 localhost.localdomain gnome-session[2507]: WARNING: App 'gnome-shell.desktop' respawning too quickly
Jan 31 13:31:01 localhost.localdomain gnome-session[2507]: WARNING: Detected that screensaver has left the bus
[root@localhost ~]# 

[root@localhost ~]# cat /usr/lib/systemd/system/vncserver@:1.service |grep -v \#


[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=forking
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l k_georgiev -c "/usr/bin/vncserver %i"
ExecStop=/sbin/runuser -l k_georgiev -c "/usr/bin/vncserver -kill %i"

[Install]
WantedBy=multi-user.target

I am trying to login, but every time I open VNC session, I got this message
"Oh no, something has gome wrong".

Do we have any solution for this? Any ideas?
Thank you.
Comment 3 dlB 2013-02-05 19:43:31 EST
I'm also having this problem.

It appears to have to do with the Gnome 3 shell software rendering mode crashing when spawned in a VNC session.

As evidence (and as a workaround), forcing Gnome into fallback gets things running.

To do this, as the user who owns the vnc session, run:

dbus-launch gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
Comment 4 P H 2013-02-06 09:09:29 EST
Exact same issue here.

dIB: where does that line of code need to be added for the workaround.
Comment 5 Vic Sperry 2013-02-06 13:25:42 EST
Same problem here. For what it's worth, I rely on VNC because my Fedora machine is not normally connected to a monitor and keyboard. So this is a big deal to me.

As for running in fallback, I did not want to use the "dbus-launch gsettings" method because I believe this will change a config file for the user who runs the command. i.e. it'll change all gnome instances run by that user. Instead, I changed my ~/.vnc/xstartup to look like this.

#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
[ -r $HOME/.Xdefaults ] && xrdb $HOME/.Xdefaults
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    eval `dbus-launch --sh-syntax --exit-with-session`
    echo "D-BUS per-session daemon address is: \
    $DBUS_SESSION_BUS_ADDRESS"
fi

# run gnome-session in fallback mode until gnome 3 plays nice with VNC
exec gnome-session --session=gnome-fallback
Comment 6 MikeP 2013-02-07 05:51:45 EST
I can also confirm this issue and that fall back mode is a work around.

For those who followed Bug 810040 where removing fprintd made it all work in virtual machines I can confirm this DOES NOT fix this issue. I include this info to save others geting into that loop

Mike
Comment 7 NM 2013-02-07 08:12:25 EST
Unfortunately, above does not work for me as i am on gnome shell with cinnamon desktop. Wonder if this workaround can be tweaked for cinnamon? Please post if you know how ... thanks.
Comment 8 NM 2013-02-07 10:29:42 EST
gnome-session --session=cinnamon works but without panel in the bottom. Hmm ...
Comment 9 Kaloyan Mehandzhiyski 2013-02-08 02:17:10 EST
Gnome session in fallback works for me, but here comes another problem.
Anybody found out how to tweak the resolution?
The standard '-geometry 1280x1024 (or any other numbers)' usually works, but now it has no effect at all. It doesn't return any error, but the resolution is aways the same with gnome-shell and with fallback mode.

Any ideas?

Thank you.
Comment 10 Greg Treantos 2013-02-14 14:23:16 EST
FWIW if I start vncserver as root ie: #vncserver I can see Gnome 3. Starting vncserver by using systemctl fails as described in the bug using root or any other user. When I start vncserver as a regular user I get this in messages: 

Feb 14 14:20:06 localhost gnome-session[4913]: CRITICAL: unable to create directory '/run/user/0/dconf': Permission denied.  dconf will not work properly.
Feb 14 14:20:06 localhost spice-vdagent[5055]: Missing virtio device '/dev/virtio-ports/com.redhat.spice.0': No such file or directory
Feb 14 14:20:06 localhost gnome-keyring-daemon[5056]: couldn't create socket directory: Permission denied
Comment 11 Joergen Thomsen 2013-02-16 16:02:30 EST
I did the following in the home directory of user xxx to run the gnome session in fallback mode

 cp -a /etc/X11/xinit/Xclients /home/xxx/.Xclients

and added --session=gnome-fallback in line 69

if [ -n "$GSESSION" ]; then
    # by default, we run GNOME.
    exec "$GSESSION" --session=gnome-fallback


This will apparently only affect VNC sessions of the user xxx

In /usr/lib/systemd/system/vncserver@:1.service the user xxx and the screen resolution was specified

ExecStart=/sbin/runuser -l xxx -c "/usr/bin/vncserver -geometry 1920x1200 %i"
ExecStop=/sbin/runuser -l xxx -c "/usr/bin/vncserver -kill %i"

and it is working as expected
Comment 12 Joergen Thomsen 2013-02-16 19:25:32 EST
Unfortunately it is not possible to start Xvnc with a general login screen as previously possible (Fedora 17). It only displays a black screen with a mouse pointer cross that can be moved over the screen :(
Comment 13 NM 2013-02-16 20:45:57 EST
For those who use cinnamon. I was able to fix the problem removing all lines but 2 from xstartup file:

#!/bin/sh -x
gnome-session --session=cinnamon &

I did not touch or copy Xclients file and used the standard vncserver@:1.service file as above. In my case the problem was that the vncserver@:1.service started /bin/gnome-session as above instead of correct one /bin/gnome-session --session=cinnamon

Hope it helps.
Comment 14 Adam Tkac 2013-02-19 10:28:18 EST
It seems the main issue is this line in the log:

WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.

Previously, Xvnc sessions were registered via /etc/X11/xinit/xinitrc machinery (via ck-xinit-session utility) but this utility no longer exist and is marked as obsolete by systemd. I think that this is one of the systemd's progressive change which just breaks things...
Comment 15 Adam Tkac 2013-02-19 10:54:05 EST
(In reply to comment #14)
> It seems the main issue is this line in the log:
> 
> WARNING: Could not get session id for session. Check that logind is properly
> installed and pam_systemd is getting used at login.
> 
> Previously, Xvnc sessions were registered via /etc/X11/xinit/xinitrc
> machinery (via ck-xinit-session utility) but this utility no longer exist
> and is marked as obsolete by systemd. I think that this is one of the
> systemd's progressive change which just breaks things...

Yes, this idea was correct. To get gnome 3 working you must do this:

1. add "-session optional pam_systemd.so" line to /etc/pam.d/runuser-l so runuser-l will look like this:

auth            include         runuser
session         optional        pam_keyinit.so force revoke
-session        optional        pam_systemd.so
session         include         runuser

2. modify vncserver@:<display>.service
- change Type to simple
- add "-fg" parameter to "vncserver" command in ExecStart
- comment out ExecStop line

so service file can look like this:

...
[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l <user> -c "/usr/bin/vncserver -fg %i"
#ExecStop=/sbin/runuser -l <user> -c "/usr/bin/vncserver -kill %i"
...

This should be enough to get gnome 3 session working with one disadvantage - when user clicks on "logout" on the gnome panel, the whole session is terminated. However I think this is expected behaviour...
Comment 16 Chris Plummer 2013-02-19 11:21:27 EST
(In reply to comment #15)
> (In reply to comment #14)
> > It seems the main issue is this line in the log:
> > 
> > WARNING: Could not get session id for session. Check that logind is properly
> > installed and pam_systemd is getting used at login.
> > 
> > Previously, Xvnc sessions were registered via /etc/X11/xinit/xinitrc
> > machinery (via ck-xinit-session utility) but this utility no longer exist
> > and is marked as obsolete by systemd. I think that this is one of the
> > systemd's progressive change which just breaks things...
> 
> Yes, this idea was correct. To get gnome 3 working you must do this:
> 
> 1. add "-session optional pam_systemd.so" line to /etc/pam.d/runuser-l so
> runuser-l will look like this:
> 
> auth            include         runuser
> session         optional        pam_keyinit.so force revoke
> -session        optional        pam_systemd.so
> session         include         runuser
> 
> 2. modify vncserver@:<display>.service
> - change Type to simple
> - add "-fg" parameter to "vncserver" command in ExecStart
> - comment out ExecStop line
> 
> so service file can look like this:
> 
> ...
> [Service]
> Type=simple
> # Clean any existing files in /tmp/.X11-unix environment
> ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
> ExecStart=/sbin/runuser -l <user> -c "/usr/bin/vncserver -fg %i"
> #ExecStop=/sbin/runuser -l <user> -c "/usr/bin/vncserver -kill %i"
> ...
> 
> This should be enough to get gnome 3 session working with one disadvantage -
> when user clicks on "logout" on the gnome panel, the whole session is
> terminated. However I think this is expected behaviour...

Awesome - I just tried it and that fixes the issue for me.  Before I updated the  runuser-l file, I did:

rm -rf ~/.vnc
sudo systemctl stop vncserver@:1.service
vncpasswd

Then I updated the runuser-l file and the /etc/systemd/system/vncserver@:1.service file.  After doing that, I ran:

sudo systemctl daemon-reload
sudo systemctl start vncserver@:1.service

I logged onto VNC from my laptop and it showed up perfectly - no fallback mode, so my Docky bar had the right effects and looked great.  I also double checked that shutting down and restarting would still start VNC correctly without the ExecStop line in effect, and it still worked correctly (the ExecStartPre seems to handle killing old VNC sessions).

Thanks, Adam!
Comment 17 Greg Treantos 2013-02-21 08:07:46 EST
Another issue I'm seeing and not sure if it is related. If I wait for sometime and the screen locks, I can't get it to unlock. I enter the password for the user and the screen hangs.
Comment 18 Joergen Thomsen 2013-02-21 08:09:57 EST
Working for me, too. 
However, I still need a way to get to the normal login screen without having to allocate separate ports for every user.
Comment 19 L.L.Robinson 2013-02-21 15:40:01 EST
(In reply to comment #17)
> Another issue I'm seeing and not sure if it is related. If I wait for
> sometime and the screen locks, I can't get it to unlock. I enter the
> password for the user and the screen hangs.

I've filed another bug for that here
https://bugzilla.redhat.com/show_bug.cgi?id=912892
Comment 20 sh0men 2013-03-23 11:26:24 EDT
I've the same issue here. Tried the suggested steps, but I still have the black "Sorry" screen after a while and a Logout button.
I don't get any new login window afterwards.
Comment 21 ipopipo 2013-03-26 06:00:43 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > It seems the main issue is this line in the log:
> > 
> > WARNING: Could not get session id for session. Check that logind is properly
> > installed and pam_systemd is getting used at login.
> > 
> > Previously, Xvnc sessions were registered via /etc/X11/xinit/xinitrc
> > machinery (via ck-xinit-session utility) but this utility no longer exist
> > and is marked as obsolete by systemd. I think that this is one of the
> > systemd's progressive change which just breaks things...
> 
> Yes, this idea was correct. To get gnome 3 working you must do this:
> 
> 1. add "-session optional pam_systemd.so" line to /etc/pam.d/runuser-l so
> runuser-l will look like this:
> 
> auth            include         runuser
> session         optional        pam_keyinit.so force revoke
> -session        optional        pam_systemd.so
> session         include         runuser
> 
> 2. modify vncserver@:<display>.service
> - change Type to simple
> - add "-fg" parameter to "vncserver" command in ExecStart
> - comment out ExecStop line
> 
> so service file can look like this:
> 
> ...
> [Service]
> Type=simple
> # Clean any existing files in /tmp/.X11-unix environment
> ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
> ExecStart=/sbin/runuser -l <user> -c "/usr/bin/vncserver -fg %i"
> #ExecStop=/sbin/runuser -l <user> -c "/usr/bin/vncserver -kill %i"
> ...
> 
> This should be enough to get gnome 3 session working with one disadvantage -
> when user clicks on "logout" on the gnome panel, the whole session is
> terminated. However I think this is expected behaviour...

Thanks Adam, that did the trick! Whoohooo!
Comment 23 Fedora Admin XMLRPC Client 2013-05-13 10:54:12 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 24 Carlos Cestero 2013-06-08 18:46:18 EDT
HOW TO MAKE TIGERVNC WORK WITH FEDORA 18 - STEP BY STEP GUIDE FOR DUMMIES

1. yum -y install tigervnc-server

2. su fedora (your username, not fedora)

3. vncpasswd

4. vncserver :1

5. vncserver -kill :1

6. nano /home/fedora/.vnc/xstartup (remember, fedora is an example)

#twm &
exec gnome-session &

7. (From comment #15) Add "-session optional pam_systemd.so" line to /etc/pam.d/runuser-l so runuser-l will look like this:

auth            include         runuser
session         optional        pam_keyinit.so force revoke
-session        optional        pam_systemd.so
session         include         runuser

8. Edit vncserver@.service under /lib/systemd/system

nano /lib/systemd/system/vncserver@.service and insert a valid user to replace <USER>

ExecStart=/sbin/runuser -l <USER> -c “/usr/bin/vncserver %i” change to

ExecStart=/sbin/runuser -l fedora -c “/usr/bin/vncserver %i”  where fedora is the user you want to run the session as.

9. (From comment #15) Also change Type=simple and add -fg to vncserver@.service...

Should look like this: (Copy & Paste it, remember to replace fedora with your username) 

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l fedora -c "/usr/bin/vncserver -fg %i"
ExecStop=/sbin/runuser -l fedora -c "/usr/bin/vncserver -kill %i"

10. Reload the configuration change:

systemctl daemon-reload

11. Edit line:

nano /usr/bin/vncserver  (and look for the following line and replace geometry with your choice)

$geometry = "1366x768";

12. Enable the vnc service:

systemctl enable vncserver@:1.service

13. DONE! WORKING TIGERVNC WITH F18!
Comment 25 Sidney Markowitz 2013-06-23 09:13:02 EDT
I got the same problem. It was after using fedup to upgrade from Fedora 17 to 18.

The suggestion in comment #15 changed the symptoms, but still does not work. Now, as before, I still can get vnc to work by running it directly from the command line with

 vncserver :2

But when I kill that session and try to run it with runuser by doing
 sudo systemctl start vncserver\@:2.service
the log file ends with

 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on all interface(s), port 5902
 vncext:      created VNC server for screen 0
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":2"
      after 141 requests (141 known processed) with 0 events remaining.

(imsettings-check:3434): IMSettings-WARNING **: Could not connect: Connection refused

(imsettings-check:3434): GLib-GIO-CRITICAL **: g_dbus_proxy_call_sync_internal: assertion `G_IS_DBUS_PROXY (proxy)' failed

** (gnome-session:3328): WARNING **: Could not open X display

** (gnome-session:3328): WARNING **: Cannot open display:
Comment 26 v.ronnen 2013-07-10 03:15:08 EDT
Same problem on fedora 19
caused by prorogation of environment var XDG_RUNTIME_DIR, with value XDG_RUNTIME_DIR=/run/user/0

After su/runuser XDG_RUNTIME_DIR still points to /run/user/0, which is owned by root. Of course a non root user cannot write to this directory
 
Solution to be included in tigervnc-server rpm:

Edit the user's .vnc/xstartup:

after unset DBUS_SESSION_BUS_ADDRESS
add
unset XDG_RUNTIME_DIR

change /etc/X11/xinit/Xclients:
if [ -n "$GSESSION" ]; then
    # by default, we run GNOME.
    # olc exec "$GSESSION"
    exec "$GSESSION" --session=gnome-classic

and install gnome-classic-session rpm, Which is a great improvement (not!) to the FC18 solution of --session=gnome-fallback. (And this shows why linux sucks. I agree to the opinion of Bryan Lunduke. Useless changes makes linux sucks.)
Comment 27 Mark 2013-07-15 03:08:44 EDT
Still broken as of this date.  This was working fine in Fedora 18, Fedora 19 the service dies on start.
Comment 28 Mark 2013-07-21 12:59:37 EDT
Still broken.
Comment 29 Carlos Cestero 2013-07-24 11:35:33 EDT
Solution #24 still works on F19... done it on 3 laptops.
Comment 30 Carlos Cestero 2013-07-24 12:26:40 EDT
Now, is there a tested fully working  way to use tigervnc with cinnamon on Fedora 19?
Comment 31 Chris Plummer 2013-07-25 12:24:10 EDT
Carlos' solution worked for me on F19, but the geometry settings are wrong no matter what I do - it's defaulting to some value that I can't seem to override.  I've tried:

- editing /usr/bin/vncserver
- putting '-geometry 800x600' into /etc/systemd/system/vncserver@:1.service, in the 'ExecStart'
- running 'vncserver :1 -geometry 800x600'

This is (one of a few reasons) why I've been using Ubuntu lately - this kind of stuff seems to break in Fedora every release.
Comment 32 Carl Hinton 2013-08-19 05:33:51 EDT
I have tried all of the above - and it's still not working on F19
This has been broken since January - and it sucks
Comment 33 jeff 2013-08-21 21:03:39 EDT
Tried all of the suggestions, vnc start with black screen. so connection works gnome doesn't..

Had to replace gnome with KDE on the Fedora 18 system to get a desktop to work.  Will try that tomorrow.

G  Graphics
N  not 
O  operational 
M  must
E  exit

More to come tomorrow..
Comment 34 jeff 2013-08-22 15:04:43 EDT
Installed Mate, Cinnamon and KDE...  All work at console even Gnome... 

Back to VNC...

Workaround is:

With "KDE Plasma Workspaces" installed create a file /etc/sysconfig/desktop containing 
DESKTOP="KDE"
DISPLAYMANAGER="KDE"

Now according to the the docs form here http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Desktop.html

systemctl is supposed to do this now, maybe not so much. 

Old config found here:
http://fedoraproject.org/wiki/KDE

And yes I did try it with DESKTOP="GNOME" and DISPLAYMANAGER="GNOME"  no luck..

GNOME pretty much broken... unless you are on the console.
Comment 35 Mark 2013-08-23 11:45:42 EDT
I'm beginning to think this ticket has been abandoned by the dev team.
Comment 36 jeff 2013-08-24 11:54:14 EDT
A bit more testing today seems to point directly to Gnome.  

Tried to set up a mate desktop and same issue only a bit better at least there you get a logout option.  Since Mate is dependent on gnome...  all roads lead to Gnome..

Should be reclassified as a Gnome bug.. as vnc works with KDE;)
Comment 37 Tim Waugh 2013-08-27 08:34:04 EDT
This bug is marked as being dependent on bug #912778... until that bug is confirmed as fixed, no progress can be made on this one.
Comment 38 rts 2013-09-18 16:52:19 EDT
if this helps any...

TigerVNC server appears to fail with machines upgrades from FC18 to FC19 with fedeup.  With fresh install, vncserver works without issue.

Setting service type to 'simple' and adding '-fg' in ExecStart line as in comment #24 allows server to run.  Since I don't care for the new GNOME desktop, this has only been tried with xfce.  Be sure to set service type to simple else excessive log entries will create a huge vnc log file.
Comment 39 Pierre Ossman 2013-09-24 04:55:17 EDT
There is also bug 959941 that is about that Gnome should be able to run without a logind session.
Comment 40 Steve 2013-10-08 08:07:57 EDT
I had this working with a combination of the above suggestions, but it broke again following a recent 'yum update'. What finally got it working again was a variation of the method in comment #13, replacing 'gnome-session --session=cinnamon' with 'cinnamon-session'.

Make sure you have /usr/bin/cinnamon-session before trying this, it seems to be a fairly recent addition to the Fedora cinnamon suite.
Comment 41 Bob Gustafson 2013-10-08 08:43:04 EDT
(In reply to rts from comment #38)
> 
> TigerVNC server appears to fail with machines upgrades from FC18 to FC19
> with fedeup.  With fresh install, vncserver works without issue.

This is a substantial clue. Do a fresh install and diff the config files. I assume that you have done this to get the suggestion below.

Does it work with plain vanilla Gnome?

> Setting service type to 'simple' and adding '-fg' in ExecStart line as in
> comment #24 allows server to run.  Since I don't care for the new GNOME
> desktop, this has only been tried with xfce.  Be sure to set service type to
> simple else excessive log entries will create a huge vnc log file.
Comment 42 Bob Gustafson 2013-11-05 11:14:29 EST
I tried to vnc into this machine from another machine on my LAN. On each try, the connection would seem to hang just at the end of typing in my password (and return).

I set up Wireshark to check the login - it seems that the login is successful (note Authentication result: OK - at the bottom of the middle pane of attached Screenshot.png)

(...21 is me, ...51 is the target machine, but for X sessions the server is me and the client is the target)

Further on in the conversation between client and server, things seem to go wrong - there is an

Unknown server message type

and then an

Unknown client message type (248)

The conversation just loops at this point, with Unknown server message type and Unknown client message type.

-------

The last thing to happen before things go wrong is a client framebuffer update request, followed by two zero length packets from the target machine.

See attached screenshots.
Comment 43 Bob Gustafson 2013-11-05 11:17:13 EST
Created attachment 819866 [details]
See comment 42 - this is first screenshot
Comment 44 Bob Gustafson 2013-11-05 11:18:24 EST
Created attachment 819867 [details]
See comment 42 - this is second screenshot
Comment 45 Bob Gustafson 2013-11-05 11:25:37 EST
(In reply to Bob Gustafson from comment #42)

On the target machine ...51

  Xvnc TigerVNC 1.3.0 - built Sep 24 2013 16:34:47


On the user machine ...21

  TigerVNC Viewer 64-bit v1.3.0 (20130924)
  Built on Sep 24 2013 at 16:32:56
Comment 46 Bob Gustafson 2013-11-18 11:08:25 EST
(In reply to Bob Gustafson from comment #42)
> I tried to vnc into this machine from another machine on my LAN. On each
> try, the connection would seem to hang just at the end of typing in my
> password (and return).
> 

To make the above more precise, there are TWO logins:

1) The first login, which requires the vncpasswd to match, succeeds for me. I get a full screen display similar to that shown when you have a normal console after clicking on 'lock'. Essentially, the system knows that a particular user logged in (my name is at the upper left), but the screen is in the lock state.

2) The second login happens when I click on the RETURN key. The display changes and shows a password request field (for the previous 'logged in' VNC user).

An odd thing is that it shows 'authentication error', even though no password has been attempted, just the initial RETURN that got the password request field.

When a good password is used, when the final RETURN key is pressed a little spin indicator shows just to the left of the greyed out 'Unlock' button. This continues until the 'Cancel' button is clicked.

This 2nd login is never successful.

[Perhaps Gnome is started under systemd in the normal console login, but is started under some other rule set when started by the xstart of VNC?]

-------

Under some conditions (not fully characterized - soon after the server restart), the Gnome screen which appears after the 1st login, is the successful logged in screen! It seems as though there is a window of time where a password is not needed to login the 2nd time!

Hope these observations help.
Comment 47 Bob Gustafson 2013-11-19 01:27:05 EST
(In reply to Bob Gustafson from comment #46)
> (In reply to Bob Gustafson from comment #42)

> Under some conditions (not fully characterized - soon after the server
> restart), the Gnome screen which appears after the 1st login, is the
> successful logged in screen! It seems as though there is a window of time
> where a password is not needed to login the 2nd time!

In this window of 'no password required', there are TWO little 'VNC config' windows open. See attached screen dump

Also, here is a view of what is running on the server system

[user1@hoho6 ~]$ ssh hoho0
user1@hoho0's password: 
Last login: Tue Nov 19 00:11:06 2013 from hoho6.chidig.com
[user1@hoho0 ~]$ 
[user1@hoho0 ~]$ ps ax | grep vnc
 1076 ?        Ss     0:00 /sbin/runuser -l user1 -c /usr/bin/vncserver -fg :1
 1214 ?        Ss     0:00 /usr/bin/perl /usr/bin/vncserver -fg :1
 1308 ?        Sl     0:02 /usr/bin/Xvnc :1 -desktop hoho0.chidig.com:1 (user1) -auth /home/user1/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/user1/.vnc/passwd -rfbport 5901 -fp catalogue:/etc/X11/fontpath.d -pn
 1417 ?        S      0:00 /usr/bin/vncconfig -iconic
 1418 ?        S      0:00 sh -c /home/user1/.vnc/xstartup >> '/home/user1/.vnc/hoho0.chidig.com:1.log' 2>&1
 1420 ?        S      0:00 vncconfig -iconic
 2219 pts/0    S+     0:00 grep --color=auto vnc
[user1@hoho0 ~]$ 

It is 'yum update'd as of a few moments ago, rebooted (to give a 'no password' time window)

[user1@hoho0 ~]$ uname -a
Linux hoho0.chidig.com 3.11.8-200.fc19.x86_64 #1 SMP Wed Nov 13 16:29:59 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[user1@hoho0 ~]$
Comment 48 Bob Gustafson 2013-11-19 01:29:48 EST
Created attachment 825904 [details]
Successful entry during 'no password' time window - shows TWO VNC config windows
Comment 49 Pierre Ossman 2013-11-19 06:40:42 EST
That sounds like bug 960149, which is a different issue from that of not being able to start Gnome at all.
Comment 50 Bob Gustafson 2013-11-19 12:24:46 EST
Yes, bug 960149 is close, but trying Mornati's fixes did not solve my 'entry using VNC' problem.

I left a comment there.
Comment 51 Bob Gustafson 2013-11-19 12:31:16 EST
(In reply to Bob Gustafson from comment #50)
> 
> I left a comment there.

Where 'there' is

http://blog.mornati.net/2013/03/25/fedora-18-cant-unlock-the-screen/
Comment 52 Pierre Ossman 2013-11-20 02:23:27 EST
(In reply to Bob Gustafson from comment #50)
> Yes, bug 960149 is close, but trying Mornati's fixes did not solve my 'entry
> using VNC' problem.
> 

Not surprising as Mornati is describing a different bug. The only relevant part of that blog was that you have to kill gnome-shell to force an unlock.
Comment 53 Bob Gustafson 2013-11-24 08:21:56 EST
Another oddity:

The login screen on my console includes a little option for selecting the desktop (includes gnome and openbox).

When I login using VNC, I don't see that option. Is this significant relative to the problem?
Comment 54 Mark 2013-12-09 07:29:06 EST
This is still a problem, so I'm not using Fedora at all at the moment.

Does anyone know if this is fixed in F20?
Comment 55 Bob Gustafson 2013-12-10 11:25:47 EST
This has got to be a simple problem..

--------

Another observation with latest yum update

I reboot my vncserver system and look at the ps ax of the vnc

[user1@hoho6 ~]$ ps ax | grep vnc
 1246 ?        Ss     0:00 /sbin/runuser -l user1 -c /usr/bin/vncserver -fg :1
 1302 ?        Ss     0:00 /usr/bin/perl /usr/bin/vncserver -fg :1
 1594 ?        Sl     0:00 /usr/bin/Xvnc :1 -desktop hoho6.chidig.com:1 (user1) -auth /home/user1/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/user1/.vnc/passwd -rfbport 5901 -fp catalogue:/etc/X11/fontpath.d -pn
 1742 ?        S      0:00 /usr/bin/vncconfig -iconic
 1743 ?        S      0:00 sh -c /home/user1/.vnc/xstartup >> '/home/user1/.vnc/hoho6.chidig.com:1.log' 2>&1
 3526 pts/0    S+     0:00 grep --color=auto vnc
[user1@hoho6 ~]$ date
Tue Dec 10 09:56:14 CST 2013
[user1@hoho6 ~]$ uname -a
Linux hoho6.chidig.com 3.11.10-200.fc19.x86_64 #1 SMP Mon Dec 2 20:28:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[user1@hoho6 ~]$

--------

Then I quickly log in from a different F19 system - using TigerVNC viewer as before.

I log in quickly, because the vncserver system has a time window after boot where it is possible to log in via vnc without needing to log in with a password after the initial vnc session is established. (See comment #42 and comment #47 above)

Then, I do something different - I do a Log Out from the pulldown panel at the right top of the window. It does log out.

When I try to connect with vnc again from the different system, I get a 111 refusal. This is odd - I should be able to log in again, yes?

--------

Then I go back to the vncserver system and look at the ps ax state of the vnc.

I see:

[user1@hoho6 ~]$ ps ax | grep vnc
 5180 pts/0    S+     0:00 grep --color=auto vnc
[user1@hoho6 ~]$

All of the vnc has been blown away!
Comment 56 Bob Gustafson 2013-12-11 12:14:11 EST
It is not necessary to use a remote computer to demonstrate the Log Out problem.

It can be demonstrated by logging into the vncserver computer using a vncviewer on the same computer.

It is only possible to log on via VNC during the 'root permissions time window' soon after a boot.

The steps are:

1) Reboot vncserver computer

2) log into vncserver computer using vncviewer soon after the boot.

3) Check whether vncserver is running (of course it is running, how else would you be able to log on..) with ps ax | grep vnc

4) From within VNC session, do a Log Out from the pull down menu from your login name at the top right of the VNC viewer window.

5) VNCviewer window disappears from your screen leaving the console window still open.

6) Check whether vncserver is running - Nope, blown away.

=====

Here is a guess at what is happening:

There is a state machine running (somewhere) which keeps root permissions for a limited time on the console. During this time, it is possible to log into the vncserver with a vncviewer - no second password is requested because the sessions are already running with root permissions.

A Log Out, with this 'root permission state', can do bad things, like killing the vncserver itself.

Within this VNC session, from a terminal session, I could also do a shutdown of the computer - without a sudo. It was as if I was running as root - even though I had logged into the VNC session using my user1 name.

I did not test whether this 'root permission state' persists for longer than the normal sudo timeout.

------
If I wait for awhile after the boot of the vncserver system - enough time so the permissions of new sessions relaxes to their own native permission level, it is not possible to log into Gnome from a VNCviewer session because there is now a permission conflict.
Comment 57 Bob Gustafson 2013-12-14 15:06:48 EST
(In reply to Bob Gustafson from comment #56)
> 
> I did not test whether this 'root permission state' persists for longer than
> the normal sudo timeout.
> 

I had a chance to test this - more or less. On the same machine, I logged in to the vncserver with the vncviewer soon after a reboot. I only had to give my password once. I opened a viewer and did the ps ax | grep vnc and the result showed all of the vnc components running normally.

Then I did not touch it for awhile - after about 15 minutes, the automatic screen lockout engaged.

I then could not log back in. It was the same as if I had waited the same length of time before logging in with vncviewer. I see the time of day screen, then I hit return and get a text input window asking for a password. I put the password in and get the little spinning wait icon...

I closed the vncviewer session using the 'X' at the upper right of the vncviewer window. Doing ps ax | grep vnc from the console screen showed that all the vnc components were working fine.

-----

So, there may be two different timeouts involved. The 'sudo permissions timeout' which seems to be engaged at reboot. There is also the 'screen lock timeout' which looks for periods of inactivity - if long enough, it locks the screen.

The observed behaviour may be from just the 'screen lock timeout'. Another test I could do would be to reboot, login using the vncviewer, and then do things often enough to keep the 'screen lock' from timing out. Part of this activity would be to test whether the session is in any enhanced permission state (sudo) and whether that enhanced permission state has a timeout which is independent of the 'screen lock timout'.

---------

I am acting here as a pre-DNA doctor on a patient - trying stuff and looking for a logical pattern which might lead someone with more knowledge to the solution. (Or an alley mechanic - working on a modern MB S600)

Then again, maybe the solution is already in F20. Unfortunately, on 12/17, I will be 5000 miles away from this system.
Comment 58 Bob Gustafson 2013-12-15 09:29:32 EST
There were a lot of changes in the latest yum update.

After updating, and before I logged in at the console, I logged in using my iPad with the VNC app. (This was very soon after rebooting after the update).

I got in to my Gnome screen without the 2nd password needed. To check whether I was temporarily in some sort of enchanced security state, I tried to look at the system log file - tail /var/log/messages. The system very properly said I could not, so at least in that respect, there wasn't any 'enhanced security state'.

However, rather than waiting for the session to time out and lock the screen, I did a 'Log Out' from the Gnome pulldown at top window right. Note that this is on my iPad.

I then logged into the vncserver system console and did ps ax | grep vnc

All of the vnc components had blown away as noted previously.

The new updates did not seem to affect the previously noted symptoms.
Comment 59 Pierre Ossman 2013-12-16 01:49:07 EST
I'm sorry to say this, but you are mostly filling this bug entry with useless noise as you lack information on how the system is put together.

1. VNC sessions are started as a specific user. There is no login like there is locally. You are only authenticating with VNC, not as the user. That is also why you can not choose a desktop environment. It is already running.

2. There is no second login. That's just the screen saver. Nothing magical about this. It is simply buggy and is unable to unlock under VNC.

3. Since there is no login, terminating your desktop (i.e. logging out) kills your VNC server. There is nothing left to show so there is no point in leaving it running.
Comment 60 Bob Gustafson 2013-12-16 08:24:19 EST
(In reply to Pierre Ossman from comment #59)
> I'm sorry to say this, but you are mostly filling this bug entry with
> useless noise as you lack information on how the system is put together.

Thanks for filling in some of the details. I thought somebody would come along sooner or later..

> 
> 1. VNC sessions are started as a specific user. There is no login like there
> is locally. You are only authenticating with VNC, not as the user. That is
> also why you can not choose a desktop environment. It is already running.

Yes, this is the 1st login. And the choice of desktop is done at VNCserver configuration and start - which is usually at boot time.

> 
> 2. There is no second login. That's just the screen saver. Nothing magical
> about this. It is simply buggy and is unable to unlock under VNC.

Buggy yes. For about 11 months.

> 
> 3. Since there is no login, terminating your desktop (i.e. logging out)
> kills your VNC server. There is nothing left to show so there is no point in
> leaving it running.

I'm not so sure this is the desired behavior. A Log Out on the console offers the possibility of logging in again as the same user. A Log Out on the VNCviewer session kills the VNCserver and prevents that same user from logging in again through VNC - until the VNCserver machine is rebooted - which might be months later.

Perhaps a Log Out, but then a 'restart' of the VNCserver for that user - so it is waiting for the next VNC login.
Comment 61 Fedora End Of Life 2013-12-21 10:17:58 EST
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 62 Bob Gustafson 2014-01-29 09:53:44 EST
Since it hasn't been fixed yet - not even in F20, why not up the version to 20.
Comment 63 Joergen Thomsen 2014-01-29 11:08:06 EST
+1 from here
Comment 64 NM 2014-01-29 11:17:37 EST
Indeed.
Comment 65 Paul Wouters 2014-02-07 18:56:05 EST
From my experience, the session creates a new ~vnc/.Xstartup from template which requires both twm and xterm. These are not listed as Requires: for tightvnc-server (Requires: xorg-x11-twm xterm)

Or perhaps this script needs updating to use gnome-session instead (with a Requires: gnome-session)
Comment 66 Tim Waugh 2014-02-10 06:03:11 EST
(In reply to Paul Wouters from comment #65)
> From my experience, the session creates a new ~vnc/.Xstartup from template
> which requires both twm and xterm. These are not listed as Requires: for
> tightvnc-server (Requires: xorg-x11-twm xterm)

No. What is required is a functioning /etc/X11/xinit/xinitrc -- and this is in the package requirements list. (We keep the twm/xterm lines to avoid unnecessary changes from upstream.)

> Or perhaps this script needs updating to use gnome-session instead (with a
> Requires: gnome-session)

No, that would be entirely incorrect. Desktop choice is already handled by xinitrc.
Comment 67 Bob Gustafson 2014-04-18 19:44:06 EDT
This is an update - I seem to have something working.

On an updated Fedora 20 x64 system

yum install vino

*** vino-3.10.1

reboot, check to see if vino-server is running
ps ax | grep vino
*** nnn ?   SLl  0:00 /usr/libexec/vino-server


yum install dconf-editor

run dconf-editor under your own username  (running under root is read-only)

Navigate to /org/gnome/desktop/remote-access

Change the checkmarked boxes to match with the screen capture (next comment box in this bugzilla entry). The password entered in the vnc-password box is a base64 encoded version of the password you want to use for VNC access. The default is to use the GNOME keyring, but I was not able to get the keyring working (used login key, but..)

Note also that there is NO ENCRYPTION running with this configuration. Best to use in only in a network protected by another firewall.

------

Using TigerVNC Viewer 64-bit v1.3.0 (20140319) running on a F19 system, I was able to log into the vino-server system using the VNC password. If the vino-server system was asleep or screen-locked, the remote screen shows the default time-of-day screen (wakes up vino-server system). Hit return and the please enter password screen comes up - you must log in with your login password, not the VNC password here.


I was able to logout from the remote screen - the screen went black, then the default time-of-day screen came up - as it should. I was able to login successfully again (using my login password) after hitting return, which brought up the login window.

After killing the remote screen (upper-right X), I was able to connect remotely again (using the VNC password). Have fun.
Comment 68 Bob Gustafson 2014-04-18 19:46:11 EDT
Created attachment 887660 [details]
Screen shot showing dconf-editor with remote-access settings used.
Comment 69 Bob Gustafson 2014-04-18 19:55:38 EDT
Port 5900 was used in the TigerVNC Viewer

<my vino-server system IP>:5900
Comment 70 Bob Gustafson 2014-04-21 14:48:51 EDT
I am able to use the iPhone App VNC 2.2.3.002740 Co RealVNC 2010-2014
to log in and write this bugzilla entry.

The ovn-screen keyboard is a little inconvenient, but possible.

The connection is wireless and both iPhone and server are inside 'safe' LAN, so
encryption is not used - but, I will be looking for an encrypted solution.

Sent from my iPhone.
Comment 71 Kun Tan 2014-05-08 04:53:21 EDT
(In reply to Bob Gustafson from comment #67)
> This is an update - I seem to have something working.
> 
> On an updated Fedora 20 x64 system
> 
> yum install vino
> 
> *** vino-3.10.1
> 
> reboot, check to see if vino-server is running
> ps ax | grep vino
> *** nnn ?   SLl  0:00 /usr/libexec/vino-server
> 
> 
> yum install dconf-editor
> 
> run dconf-editor under your own username  (running under root is read-only)
> 
> Navigate to /org/gnome/desktop/remote-access
> 
> Change the checkmarked boxes to match with the screen capture (next comment
> box in this bugzilla entry). The password entered in the vnc-password box is
> a base64 encoded version of the password you want to use for VNC access. The
> default is to use the GNOME keyring, but I was not able to get the keyring
> working (used login key, but..)
> 
> Note also that there is NO ENCRYPTION running with this configuration. Best
> to use in only in a network protected by another firewall.
> 
> ------
> 
> Using TigerVNC Viewer 64-bit v1.3.0 (20140319) running on a F19 system, I
> was able to log into the vino-server system using the VNC password. If the
> vino-server system was asleep or screen-locked, the remote screen shows the
> default time-of-day screen (wakes up vino-server system). Hit return and the
> please enter password screen comes up - you must log in with your login
> password, not the VNC password here.
> 
> 
> I was able to logout from the remote screen - the screen went black, then
> the default time-of-day screen came up - as it should. I was able to login
> successfully again (using my login password) after hitting return, which
> brought up the login window.
> 
> After killing the remote screen (upper-right X), I was able to connect
> remotely again (using the VNC password). Have fun.

Thanks, Bob. This works for me!
I'm using clean FC20 system with Gnome3. 

One comment for the vino install part:
I found vino is already installed in my system, but it was not started.
So run command "/usr/libexec/vino-server" and got following warnnings

[root@localhost ~]# ps -au | grep vino
root      2705  0.0  0.0 112664   956 pts/0    S+   16:28   0:00 grep --color=auto vino
[root@localhost ~]# /usr/libexec/vino-server 

(vino-server:2720): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion 'global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed
** Message: The desktop sharing service is already running, exiting.
[root@localhost ~]# ps au | grep vino
root      2728  0.0  0.0 112664   956 pts/0    S+   16:29   0:00 grep --color=auto vino
Comment 72 Mike 2014-05-18 14:45:57 EDT
(In reply to jeff from comment #34)

Thank you Jeff (comment #34) this worked.
Comment 73 Jonathan Underwood 2015-01-23 17:10:35 EST
OK, so as far as I can see, this is still broken in Fedora 20 - that vino works is great, but that's a different topic really - vino has a different use case.
Comment 74 john casey 2015-02-13 04:01:50 EST
Ok - As far as I can see, this is still broken in Fedora 21.   VINO is not a solution - it's a different use case.
Comment 75 Bob Gustafson 2015-02-13 11:36:52 EST
(In reply to john casey from comment #74)
> Ok - As far as I can see, this is still broken in Fedora 21.   VINO is not a
> solution - it's a different use case.

Could you elaborate a bit on the different use cases?

I'm using vino from Florida right now. It works fine for my use case!
Comment 76 john casey 2015-02-23 01:39:40 EST
>Could you elaborate a bit on the different use cases?

Vino only replicates the current desktop.   VNCSERVER provides multiple remote desktops.  these are two different use cases.  I'm glad vino works for you, but vino single desktop is not what this thread is about.
Comment 77 Kappa 2015-04-29 22:28:49 EDT
I experienced this bug using the built in GNOME Remote Desktop Viewer. Both my client and server are running Fedora 21 Workstation. I enable desktop sharing on the server machine with password. When I connect from the client it gives me this message:

"Oh no! Something has gone wrong. A problem has occurred and the system can't recover. All extensions have been disabled as a precaution."

However, when I hook a monitor directly up to the server it appears GNOME is either still running or restarted. I am able to login and use it normally. 

I went through the comments and tried setting GNOME to fall back but that did not work. Following Adam Tkac's advice above I edited runuser-l on the server. That fixed it for me. I did not need to do the second step. I can now connect with GNOME Remote Desktop Viewer with no problems.

Thanks
Comment 78 Kappa 2015-05-01 16:06:45 EDT
Nevermind, after further testing it appears the process of hooking up a monitor to the server machine force restarts GNOME. When I do that it gives me the login screen, even though I have automatic login ON in settings > users. After I login I am then able to disconnect the monitor and connect with VNC normally. 

After installing recent OS updates to Fedora 21 I noticed the change in runuser-l that Adam Tkac specified is already made, so that is no longer necessary. Also the /lib/systemd/system/vncserver@.service file is not there anymore, so I am at a loss for what else to try.
Comment 79 Bob Gustafson 2015-05-01 16:30:57 EDT
(In reply to Kappa from comment #78)
>  Also the /lib/systemd/system/vncserver@.service file is not there
> anymore, so I am at a loss for what else to try.

You might try vino.

vino is discussed in several comments in this bug report.
Comment 80 Fedora End Of Life 2015-05-29 04:51:26 EDT
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.
Comment 81 Fedora End Of Life 2015-06-29 20:37:03 EDT
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.
Comment 82 Jonathan Underwood 2015-06-30 03:11:53 EDT
Still an issue in F22 as far as I can see. I'll re-open.
Comment 83 Fedora Admin XMLRPC Client 2015-08-20 04:44:35 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 84 Fedora End Of Life 2016-07-19 14:50:33 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.