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?

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.

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'

Exact same issue here.

dIB: where does that line of code need to be added for the workaround.

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

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

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.

gnome-session --session=cinnamon works but without panel in the bottom. Hmm ...

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.

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

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

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

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.

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

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

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

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.

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.

(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

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.

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

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

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!

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:

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

Still broken as of this date.  This was working fine in Fedora 18, Fedora 19 the service dies on start.

Still broken.

Solution #24 still works on F19... done it on 3 laptops.

Now, is there a tested fully working  way to use tigervnc with cinnamon on Fedora 19?

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.

I have tried all of the above - and it's still not working on F19
This has been broken since January - and it sucks

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

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.

I'm beginning to think this ticket has been abandoned by the dev team.

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;)

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.

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.

There is also bug 959941 that is about that Gnome should be able to run without a logind session.

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.

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

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.

Created attachment 819866 [details]
See comment 42 - this is first screenshot

Created attachment 819867 [details]
See comment 42 - this is second screenshot

(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

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

(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 ~]$

Created attachment 825904 [details]
Successful entry during 'no password' time window - shows TWO VNC config windows

That sounds like bug 960149, which is a different issue from that of not being able to start Gnome at all.

Yes, bug 960149 is close, but trying Mornati's fixes did not solve my 'entry using VNC' problem.

I left a comment there.

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

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

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?

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?

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!

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.

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

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.

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.

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

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.

Since it hasn't been fixed yet - not even in F20, why not up the version to 20.

+1 from here

Indeed.

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)

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

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.

Created attachment 887660 [details]
Screen shot showing dconf-editor with remote-access settings used.

Port 5900 was used in the TigerVNC Viewer

<my vino-server system IP>:5900

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.

(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

(In reply to jeff from comment #34)

Thank you Jeff (comment #34) this worked.

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.

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.

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

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

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

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.

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

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.

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.

Still an issue in F22 as far as I can see. I'll re-open.

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

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.

*** Bug 1410560 has been marked as a duplicate of this bug. ***

The issue still persists and seems to be blocked by bug 959941 as other DEs works just fine (e.g. KDE).

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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

tigervnc-1.8.0-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce63021bcb

tigervnc-1.8.0-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8b51db595f

tigervnc-1.8.0-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8b51db595f

tigervnc-1.8.0-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce63021bcb

tigervnc-1.8.0-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

tigervnc-1.8.0-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.