Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1646889

Summary: Tigervnc not starting on RHEL 7.6 server without -noxstartup option
Product: Red Hat Enterprise Linux 7 Reporter: Aurélien Pupier <apupier>
Component: tigervncAssignee: Jan Grulich <jgrulich>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.6CC: afox, amike, apupier, ogondza, rstrode, tpelka, yuping.zuo+k4lb4l
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1665876 (view as bug list) Environment:
Last Closed: 2019-08-06 12:43:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1665876    
Attachments:
Description Flags
rpm -qa command result none

Description Aurélien Pupier 2018-11-06 09:00:33 UTC 
Description of problem:

tigervnc server is no more starting with RHEL 7.6 without the -noxstartup option

There is no xstartup file in .vnc folder in our case.


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


How reproducible:


Steps to Reproduce:
(guessing simple steps)
1. use rhel server 7.6
2. install tigervnc
script used in our CI to setup it
#
# Install and setup VNCServer for Fuse Tools jobs
# RHEL 7 instructions are here   https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-TigerVNC.html
#
yum install -y tigervnc-server
cp /usr/lib/systemd/system/vncserver\@.service /etc/systemd/system/vncserver\@.service
sed -i 's/<USER>/jenkins/g' /etc/systemd/system/vncserver\@.service
systemctl daemon-reload
and also
3. set the vnc password
4. launch vncserver :$DISPLAY_NUMBER -localhost -nolisten tcp

Actual results:

vnc server is not starting.
there is this in vnc log:

Xvnc TigerVNC 1.8.0 - built Aug 31 2018 12:04:07
Copyright (C) 1999-2017 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12001000, The X.Org Foundation
Fri Nov  2 13:15:35 2018
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on local interface(s), port 5982
 vncext:      created VNC server for screen 0
Failed to open connection to "session" message bus: /usr/bin/dbus-launch terminated abnormally without any error message
Running without a11y support!
Killing Xvnc process ID 13652
Error: cannot open display: :82


Expected results:

vncserver started

Additional info:

workaround: use -noxstartup option
it was working great with previous releases of RHEL
Comment 3 Jan Grulich 2018-11-06 11:49:24 UTC 
Can you verify it works with RHEL 7.5? I'm not aware of anything that could break this, the xstartup file should be created in the first run of vncserver.
Comment 4 Tomas Hudziec 2018-11-06 15:50:00 UTC 
I cannot reproduce on RHEL 7.6 (kernel-3.10.0-957.el7.x86_64) with tigervnc 1.8.0.13. I have no xstartup in ~/.vnc folder, and vncserver creates missing xstartup file and correctly starts.

However, if I pass the -noxstartup option, I have only black screen when connecting with vncviewer.

I guess the issue could be something related to mentioned dbus-launch in log...
Comment 5 Jan Grulich 2018-11-06 18:58:34 UTC 
From vncserver documentation:

−noxstartup
Do not run the %HOME/.vnc/xstartup script after launching Xvnc. This option allows you to manually start a window manager in your TigerVNC session.

That's why you get a black screen only, you are supposed to start everything manually.
Comment 6 Oliver Gondža 2018-11-14 15:12:10 UTC 
For what it is worth, there is a difference in the default ~/.vnc/xstartup generated by tigervnc tigervnc-1.8.0-5.el7 and 1.8.0-13.el7:

$ diff ~/.vnc/xstartup.old ~/.vnc/xstartup.new
5c5,6
< exec /etc/X11/xinit/xinitrc
---
> /etc/X11/xinit/xinitrc
> vncserver -kill $DISPLAY

Eliminating the last line did the trick.
Comment 7 Ray Strode [halfline] 2018-11-14 18:53:40 UTC 
Would you mind posting your ~/.Xclients file ?
Comment 8 Aurélien Pupier 2018-11-15 07:14:42 UTC 
I don't have any .Xclients file folder.

content of ~ after starting a vnscserver with -xnostartup


drwx------. 15 jenkins jenkins   4096 Nov 15 07:12 .
drwxr-xr-x.  3 root    root        21 Dec 14  2017 ..
-rw-r--r--.  1 jenkins jenkins     18 Aug  3  2017 .bash_logout
-rw-r--r--.  1 jenkins jenkins    193 Aug  3  2017 .bash_profile
-rw-r--r--.  1 jenkins jenkins    284 Nov 14 16:19 .bashrc
drwxrwxr-x.  2 jenkins jenkins     21 Nov 15 01:54 .camel
drwxrwxr-x.  4 jenkins jenkins     36 Nov 14 21:39 .embedmongo
-rw-r--r--.  1 jenkins jenkins     63 Nov 14 16:19 .gitconfig
drwxrwxr-x.  3 jenkins jenkins     20 Nov 14 22:39 .groovy
drwxrwxr-x.  3 jenkins jenkins     19 Nov 14 16:19 .jenkins
drwxrwxr-x.  3 jenkins jenkins     32 Nov 14 16:20 jenkins-slave
drwxrwxr-x.  4 jenkins jenkins     88 Nov 14 22:37 .m2
-rw-rw-r--.  1 jenkins jenkins   7854 Nov 14 18:05 maven33-agent.jar
-rw-rw-r--.  1 jenkins jenkins  20764 Nov 14 18:05 maven33-interceptor.jar
-rw-rw-r--.  1 jenkins jenkins   6890 Nov 14 18:05 maven3-interceptor-commons.jar
drwxrwxr-x.  2 jenkins jenkins     39 Nov 14 16:20 .oracle_jre_usage
drwxrw----.  3 jenkins jenkins     19 Nov 14 16:19 .pki
drwxrwxr-x.  4 jenkins jenkins     34 Nov 14 16:19 remoting
-rw-rw-r--.  1 jenkins jenkins 775665 Nov 14 16:19 remoting.jar
drwx------.  2 jenkins jenkins     62 Nov 14 16:19 .ssh
drwxrwxr-x.  4 jenkins jenkins     74 Nov 14 18:04 tools
drwxr-xr-x.  2 jenkins jenkins    112 Nov 15 07:12 .vnc
drwxrwxr-x.  5 jenkins jenkins    231 Nov 15 03:43 workspace
-rw-------.  1 jenkins jenkins    224 Nov 15 07:12 .Xauthority

content of ~/.vnc

drwxr-xr-x.  2 jenkins jenkins  112 Nov 15 07:12 .
drwx------. 15 jenkins jenkins 4096 Nov 15 07:12 ..
-rw-r--r--.  1 jenkins jenkins  332 Nov 15 07:11 config
-rw-rw-r--.  1 jenkins jenkins  424 Nov 15 07:12 fuse-jenkins-103:90.log
-rw-rw-r--.  1 jenkins jenkins    6 Nov 15 07:12 fuse-jenkins-103:90.pid
-rw-------.  1 jenkins jenkins    8 Nov 14 16:19 passwd
-rwxr-xr-x.  1 jenkins jenkins  112 Nov 15 07:11 xstartup
Comment 9 Jan Grulich 2018-11-15 07:47:34 UTC 
I think in this case it just runs /etc/X11/xinit/xinitrc where it either starts default desktop or some app like xterm, all of them are started using exec or have "&" at the end, which will cause the session to go down immediately. If you also think about use case, where you just run xterm for example and use it to start other apps, then kill it, the session will go down again.
Comment 10 Ray Strode [halfline] 2018-11-15 13:32:24 UTC 
can you post ps -ef output after logging in with -xnostartup ?
Comment 11 Aurélien Pupier 2018-11-15 15:37:39 UTC 
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 08:54 ?        00:00:12 /usr/lib/systemd/systemd --system --deserialize 28
root         2     0  0 08:54 ?        00:00:00 [kthreadd]
root         3     2  0 08:54 ?        00:00:00 [ksoftirqd/0]
root         5     2  0 08:54 ?        00:00:00 [kworker/0:0H]
root         6     2  0 08:54 ?        00:00:05 [kworker/u8:0]
root         7     2  0 08:54 ?        00:00:00 [migration/0]
root         8     2  0 08:54 ?        00:00:00 [rcu_bh]
root         9     2  0 08:54 ?        00:00:19 [rcu_sched]
root        10     2  0 08:54 ?        00:00:00 [watchdog/0]
root        11     2  0 08:54 ?        00:00:00 [watchdog/1]
root        12     2  0 08:54 ?        00:00:00 [migration/1]
root        13     2  0 08:54 ?        00:00:00 [ksoftirqd/1]
root        15     2  0 08:54 ?        00:00:00 [kworker/1:0H]
root        16     2  0 08:54 ?        00:00:00 [watchdog/2]
root        17     2  0 08:54 ?        00:00:00 [migration/2]
root        18     2  0 08:54 ?        00:00:00 [ksoftirqd/2]
root        20     2  0 08:54 ?        00:00:00 [kworker/2:0H]
root        21     2  0 08:54 ?        00:00:00 [watchdog/3]
root        22     2  0 08:54 ?        00:00:00 [migration/3]
root        23     2  0 08:54 ?        00:00:00 [ksoftirqd/3]
root        25     2  0 08:54 ?        00:00:00 [kworker/3:0H]
root        27     2  0 08:54 ?        00:00:00 [kdevtmpfs]
root        28     2  0 08:54 ?        00:00:00 [netns]
root        29     2  0 08:54 ?        00:00:00 [khungtaskd]
root        30     2  0 08:54 ?        00:00:00 [writeback]
root        31     2  0 08:54 ?        00:00:00 [kintegrityd]
root        32     2  0 08:54 ?        00:00:00 [bioset]
root        33     2  0 08:54 ?        00:00:00 [kblockd]
root        34     2  0 08:54 ?        00:00:00 [md]
root        40     2  0 08:54 ?        00:00:06 [kswapd0]
root        41     2  0 08:54 ?        00:00:00 [ksmd]
root        42     2  0 08:54 ?        00:00:01 [khugepaged]
root        43     2  0 08:54 ?        00:00:00 [crypto]
root        51     2  0 08:54 ?        00:00:00 [kthrotld]
root        53     2  0 08:54 ?        00:00:00 [kmpath_rdacd]
root        54     2  0 08:54 ?        00:00:00 [kpsmoused]
root        55     2  0 08:54 ?        00:00:00 [ipv6_addrconf]
root        75     2  0 08:54 ?        00:00:00 [deferwq]
root       184     2  0 08:54 ?        00:00:00 [kauditd]
root       242     2  0 08:54 ?        00:00:00 [ata_sff]
root       259     2  0 08:54 ?        00:00:00 [scsi_eh_0]
root       260     2  0 08:54 ?        00:00:00 [scsi_tmf_0]
root       261     2  0 08:54 ?        00:00:00 [scsi_eh_1]
root       262     2  0 08:54 ?        00:00:00 [scsi_tmf_1]
root       265     2  0 08:54 ?        00:00:00 [ttm_swap]
root       281     2  0 08:54 ?        00:00:00 [bioset]
root       282     2  0 08:54 ?        00:00:00 [xfsalloc]
root       283     2  0 08:54 ?        00:00:00 [xfs_mru_cache]
root       284     2  0 08:54 ?        00:00:00 [xfs-buf/vda1]
root       285     2  0 08:54 ?        00:00:00 [xfs-data/vda1]
root       286     2  0 08:54 ?        00:00:00 [xfs-conv/vda1]
root       287     2  0 08:54 ?        00:00:00 [xfs-cil/vda1]
root       288     2  0 08:54 ?        00:00:00 [xfs-reclaim/vda]
root       289     2  0 08:54 ?        00:00:00 [xfs-log/vda1]
root       290     2  0 08:54 ?        00:00:00 [xfs-eofblocks/v]
root       291     2  0 08:54 ?        00:00:09 [xfsaild/vda1]
root       359     1  0 08:54 ?        00:00:12 /usr/lib/systemd/systemd-journald
root       492     2  0 08:54 ?        00:00:00 [kvm-irqfd-clean]
root       494     2  0 08:54 ?        00:00:00 [edac-poller]
root       543     2  0 08:54 ?        00:00:01 [kworker/2:1H]
dbus       552     1  0 08:54 ?        00:00:03 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root       568     1  0 08:54 ?        00:00:02 /usr/lib/systemd/systemd-logind
root       577     1  0 08:54 ?        00:00:01 /usr/sbin/NetworkManager --no-daemon
root       699   577  0 08:54 ?        00:00:00 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/NetworkManager/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease -cf /var/lib/NetworkManager/dhclient-eth0.conf eth0
root       708     2  0 08:54 ?        00:00:02 [kworker/3:1H]
root       973     1  0 09:04 ?        00:00:28 /usr/bin/dockerd -H unix://
root       976     1  0 09:04 ?        00:00:10 /usr/bin/containerd
root       998   973  0 09:04 ?        00:01:51 containerd --config /var/run/docker/containerd/containerd.toml --log-level info
root      1017     2  0 08:54 ?        00:00:02 [kworker/1:1H]
root      1018     2  0 08:54 ?        00:00:01 [kworker/0:1H]
root      1180     1  0 08:54 tty1     00:00:00 /sbin/agetty --noclear tty1 linux
root      1181     1  0 08:54 ttyS0    00:00:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220
root     11913     1  0 08:58 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root     12161     2  0 08:59 ?        00:00:01 [kworker/3:3]
root     12930     2  0 14:42 ?        00:00:00 [kworker/3:0]
root     13648     1  0 09:06 ?        00:00:00 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
chrony   13721     1  0 09:06 ?        00:00:00 /usr/sbin/chronyd
root     13793     2  0 09:06 ?        00:00:00 [kworker/u8:1]
root     13984 19219  0 09:06 ?        00:00:00 sshd: jenkins [priv]
jenkins  13987 13984  0 09:06 ?        00:00:44 sshd: jenkins@notty
jenkins  14056 13987  0 09:06 ?        00:00:00 bash -c cd "/home/jenkins" && java -Xmx1280m -Djava.awt.headless=true -XX:+UseG1GC -XX:+UseStringDeduplication -jar remoting.jar -workDir /home/jenkins
jenkins  14065 14056  1 09:06 ?        00:07:17 java -Xmx1280m -Djava.awt.headless=true -XX:+UseG1GC -XX:+UseStringDeduplication -jar remoting.jar -workDir /home/jenkins
root     15142     2  0 09:14 ?        00:00:00 [kworker/2:7]
root     15143     2  0 09:14 ?        00:00:01 [kworker/2:8]
root     15144     2  0 09:14 ?        00:00:00 [kworker/0:0]
postfix  17274 19361  0 13:59 ?        00:00:00 pickup -l -t unix -u
root     19219     1  0 08:59 ?        00:00:00 /usr/sbin/sshd -D
root     19250     1  0 08:59 ?        00:00:00 /usr/bin/rhsmcertd
root     19361     1  0 08:59 ?        00:00:00 /usr/libexec/postfix/master -w
postfix  19363 19361  0 08:59 ?        00:00:00 qmgr -l -t unix -u
root     24341     2  0 11:01 ?        00:00:01 [kworker/0:1]
root     28400     1  0 09:00 ?        00:00:02 /usr/sbin/rsyslogd -n
root     28730     1  0 09:00 ?        00:00:00 /sbin/auditd
root     28774     1  0 09:00 ?        00:00:00 /usr/sbin/crond -n
root     28823     1  0 09:00 ?        00:00:01 /usr/sbin/irqbalance --foreground
polkitd  28873     1  0 09:00 ?        00:00:00 /usr/lib/polkit-1/polkitd --no-debug
root     28979     1  0 09:00 ?        00:00:00 rhnsd
root     29029     1  0 09:00 ?        00:00:02 /usr/bin/python2 -Es /usr/sbin/tuned -l -P
root     31728     2  0 15:14 ?        00:00:00 [kworker/1:2]
root     31793     2  0 15:24 ?        00:00:00 [kworker/1:0]
root     31808     2  0 15:30 ?        00:00:00 [kworker/1:1]
jenkins  31839     1  2 15:36 ?        00:00:00 /usr/bin/Xvnc :92 -auth /home/jenkins/.Xauthority -desktop fuse-jenkins-106:92 (jenkins) -fp catalogue:/etc/X11/fontpath.d -geometry 1024x768 -pn -rfbauth /home/jenkins/.vnc/passwd -rfbport 5992 -rfbwait 30000 -localhost -nolisten tcp
jenkins  31848 14065  0 15:36 ?        00:00:00 ps -ef
Comment 12 Ray Strode [halfline] 2018-11-15 21:36:38 UTC 
okay, so here's what I think is happening.

Normally, if vncserver is started it tries to start a desktop environment... GNOME.

If GNOME is not installed, it will desperately try other things.
It will try KDE next, and if that fails it will even try running an xterm with twm.

If it can't do that, it gives up and terminates the vnc session.  That's what I think's going on here. This install is probably extremely minimal and doesn't have a desktop environment, or twm.

7.5 had a bug where VNC wouldn't quit after the desktop logged out (or, as is the case here, I think, failed to start in the first place).

It's not clear to me how the fuse tools know the display number of the Xvnc session, but I suppose they're run "on the side" and just expect vnc to be running without a desktop environment.

So it would be bad, actually, if the xstartup stuff did work.  If the machine installed twm (or GNOME!), I bet the fuse tools would somehow malfunction, competing for the same desktop environment.

In that light, I think '-noxstartup' is actually the right command line to use for this kind of deployment.

Can you attach the output of rpm -qa on the target system?
Comment 14 Aurélien Pupier 2018-11-16 07:34:57 UTC 
Created attachment 1506332 [details]
rpm -qa command result
Comment 15 Aurélien Pupier 2018-11-16 07:38:11 UTC 
> It's not clear to me how the fuse tools know the display number of the Xvnc session, but I suppose they're run "on the side" and just expect vnc to be running without a desktop environment.

yes they are launched in same Jenkins job and so they know the display number.
When vnc is not launched, the tests are failing with "no more handles" error:

!ENTRY org.eclipse.osgi 4 0 2018-11-02 13:44:10.735
!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
	at org.eclipse.swt.SWT.error(SWT.java:4621)
	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:1033)
	at org.eclipse.swt.widgets.Display.create(Display.java:1013)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:175)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:578)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:569)
	at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:757)
	at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:163)
	at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:185)
Comment 16 Jan Grulich 2018-11-16 07:43:36 UTC 
I can try to fix it the way Ray described in comment 13.
Comment 19 Jan Grulich 2019-01-14 12:53:02 UTC 
*** Bug 1649592 has been marked as a duplicate of this bug. ***
Comment 26 Jan Grulich 2019-02-12 13:14:15 UTC 
*** Bug 1676496 has been marked as a duplicate of this bug. ***
Comment 27 Dayne Carley 2019-04-19 18:35:19 UTC 
Oliver's fix (Comment 6) worked for me.
Comment 29 Yuping Zuo 2019-07-12 01:21:27 UTC 
I'm not sure if it's related to this issue, I have a TigerVNC+GNOME setup and I tried to disable the bottom bar by uninstalling "gnome-shell-extension-window-list", and this issue happened. After I undo the uninstall everything went back to normal.

Before the undo, I tried the fix in comment 6, it worked but the resolution settings are being ignored.
After I reinstalled the package, I restored the line mentioned and it does not affect my vncserver.

The packages involved:
====================================================================================================
 Package                                  Arch          Version               Repository       Size
====================================================================================================
Removing:
 gnome-shell-extension-window-list        noarch        3.28.1-5.el7.1        @updates         55 k
Removing for dependencies:
 gnome-classic-session                    noarch        3.28.1-5.el7.1        @updates        201 k

(it may be worth mentioning that this is a CentOS 7 system though it's mostly the same as RHEL7 I think)
Comment 31 errata-xmlrpc 2019-08-06 12:43:05 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2081