TigerVNC server on CentOS 7.2

[Pat Allen]

I've been using tigervnc for years with both RHEL and CentOS 6 and 7 under VMware vSphere. I use it with xinetd so that the user gets the login screen. Everything has worked wonderfully until I upgraded CentOS to 7.2. Now Xvnc crashes whenever I try to connect to it. The package that is installed is 1.3.1-3.

Here is what I see in /var/log/messages:
Dec 21 07:19:07 pattest xinetd[4822]: START: vnc pid=4823 from=::ffff:134.89.12.58
Dec 21 07:19:07 pattest kernel: Xvnc[4823]: segfault at 0 ip 00000000005286d7 sp 00007ffe8475e6a0 error 4 in Xvnc[400000+239000]
Dec 21 07:19:07 pattest xinetd[4822]: EXIT: vnc signal=11 pid=4823 duration=0(sec)

Here is the /etc/gdm/custom.conf file:
# GDM configuration storage
[daemon]
RemoteGreeter=/usr/libexec/gdm-simple-chooser
[security]
AllowRemoteRoot=true
DisallowTCP=false
[xdmcp]
Enable=true
DisplaysPerHost=4
[greeter]
[chooser]
[debug]

Here is the /etc/xinetd.d/vnc file:
service vnc
{
type = unlisted
disable = no
flags = REUSE
socket_type = stream
port = 5901
wait = no
user = root
protocol = tcp
server = /usr/bin/Xvnc
server_args = -extension RANDR -desktop VNC-Remote-Access -inetd -query localhost -once -terminate -depth 1
6 -geometry 1280x1024 -securitytypes none
log_on_failure += USERID
}

Finally, this is the core backtrace from the rather long email sent to root:
core_backtrace:
:{ "signal": 11
:, "executable": "/usr/bin/Xvnc"
:, "stacktrace":
: [ { "crash_thread": true
: , "frames":
: [ { "address": 5408471
: , "build_id": "af3d73b00e0da5336aab9f1edd5944d8a4db2a3f"
: , "build_id_offset": 1214167
: , "function_name": "network::TcpListener::TcpListener(sockaddr const*, unsigned int)"
: , "file_name": "/usr/bin/Xvnc"
: }
: , { "address": 4488254
: , "build_id": "af3d73b00e0da5336aab9f1edd5944d8a4db2a3f"
: , "build_id_offset": 293950
: , "function_name": "displayNumFree(int)"
: , "file_name": "/usr/bin/Xvnc"
: }
: , { "address": 4511291
: , "build_id": "af3d73b00e0da5336aab9f1edd5944d8a4db2a3f"
: , "build_id_offset": 316987
: , "function_name": "ddxProcessArgument"
: , "file_name": "/usr/bin/Xvnc"
: }
: , { "address": 6031279
: , "build_id": "af3d73b00e0da5336aab9f1edd5944d8a4db2a3f"
: , "build_id_offset": 1836975
: , "function_name": "ProcessCommandLine"
: , "file_name": "/usr/bin/Xvnc"
: }
: , { "address": 5696025
: , "build_id": "af3d73b00e0da5336aab9f1edd5944d8a4db2a3f"
: , "build_id_offset": 1501721
: , "function_name": "dix_main"
: , "file_name": "/usr/bin/Xvnc"
: } ]
: } ]
:}

Can somebody give me some advice on what might be happening here? I've started looking at building from the latest source but this is a path that I'd rather not take.

THANKS!
Pat

[Pierre Ossman]

On Mon, 21 Dec 2015 08:06:17 -0800 (PST)
Pat Allen <p.t....@gmail.com> wrote:

> I've been using tigervnc for years with both RHEL and CentOS 6 and 7
> under VMware vSphere. I use it with xinetd so that the user gets the
> login screen. Everything has worked wonderfully until I upgraded
> CentOS to 7.2. Now Xvnc crashes whenever I try to connect to it. The
> package that is installed is 1.3.1-3.
>

That version is pretty ancient by now. RHEL/CentOS should really
upgrade. :/

Have you tried our build? The generic binaries should work on CentOS 7.

Rgds
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[family....@gmail.com]

Thanks for the reply, Pierre. I did install the generic 1.5 binaries on a freshly patched 7.2 CentOS system. I didn't get the segmentation fault but the connection still ends immediately. The only thing I see in the /var/log/messages file is:

Dec 23 06:48:14 pattest xinetd[1432]: START: vnc pid=12526 from=::1
Dec 23 06:48:15 pattest xinetd[1432]: EXIT: vnc status=1 pid=12526 duration=1(sec)

I'm obviously running this from the console to avoid any firewall issues although the same thing happens if I try to access it remotely.

Any other help in trying to figure this out would be GREATLY appreciated. I can't patch any of my systems until this is fixed since this breaks a key component.

THANKS!

[DRC]

On 12/23/15 3:20 AM, Pierre Ossman wrote:
>> I've been using tigervnc for years with both RHEL and CentOS 6 and 7
>> under VMware vSphere. I use it with xinetd so that the user gets the
>> login screen. Everything has worked wonderfully until I upgraded
>> CentOS to 7.2. Now Xvnc crashes whenever I try to connect to it. The
>> package that is installed is 1.3.1-3.
>>
>
> That version is pretty ancient by now. RHEL/CentOS should really
> upgrade. :/

That isn't the way RHEL works. They freeze all of the packages at a
particular feature release and source only stability improvements after
that point. So if a Red Hat user discovers a bug in TigerVNC and
reports it to Red Hat, Red Hat will add a patch to their RPM to fix the
bug, but they won't upgrade the release of TigerVNC, because that could
introduce new bugs. RHEL 6 is still stuck on TigerVNC 1.1, if that
tells you anything, and RHEL 5 (which is still in Production Phase 3
until 2017) still uses RealVNC.

[family....@gmail.com]

Interesting note... I installed the 1.6 Beta on a fresh 7.2 CentOS VM. When I try to connect I get the login screen! After logging in, the messages file is flooded with messages from gnome-session with Clutter-CRITICAL and mutter-CRITICAL. (I can post those if desired.) The desktop never displays; there's only a white screen with a little garbage in the upper-left corner. The applets (for example to logoff) display but are not functional.

I noticed in the messages file that there was also a message: "gdm: Xlib: extension "RANDR" missing on display "127.0.0.1:1". This may me experiment with the arguments to Xvnc in xinetd. I took out the "-extension RANDR" and it works "OK".

I say "OK" because there are a couple of weird things.
1. When I connect, I first get a black screen with "Authentication is required to create a color managed device". It asks for the administrator's password. Whether I cancel or enter the password, I get the login screen.
2. The applets appear to be functional but things aren't working right. If I lock the screen, I can't unlock it. And logging off closes the session but it doesn't disconnect VNC.

I can't run beta software on production systems so does this perhaps help somebody think of something that I can try to get the 1.5 software working?

THANKS again!
Pat

[Brian Hinz]

On Wed, Dec 23, 2015 at 11:12 AM,  wrote:

1. When I connect, I first get a black screen with "Authentication is required to create a color managed device". It asks for the administrator's password. Whether I cancel or enter the password, I get the login screen.

Have you tried '-depth 24'?  FWIW, I started getting the build environment ready to support CentOS 7 about two weeks ago but got pulled away to other tasks.  Hopefully before the holidays are over we'll be supplying binary packages for el7 (though I guess that won't help you until the next official release...).

 

I can't run beta software on production systems so does this perhaps help somebody think of something that I can try to get the 1.5 software working?

The official 1.6 packages will be available very soon.

-brian

[family....@gmail.com]

Thanks, Brian! That's great news and I'll look forward to the el7 packages.

Changing the depth from 16 to 24 didn't help. I still get the "Authentication is required to create a color managed device". I've looked around and found bug reports for things similar to this (http://red.ht/1QXqY62) and I've tried their workarounds but no-go so far.

As an aside, here is the current server_args line in my /etc/xinetd.d/vnc file:
-desktop VNC-Remote-Access -inetd -query localhost -once -terminate -depth 24 -geometry 1024x768 -securitytypes none

[Pierre Ossman]

On Wed, 23 Dec 2015 08:12:29 -0800 (PST)
family....@gmail.com wrote:

> I say "OK" because there are a couple of weird things.
> 1. When I connect, I first get a black screen with "Authentication is
> required to create a color managed device". It asks for the
> administrator's password. Whether I cancel or enter the password, I
> get the login screen.

Known Gnome bug that is now unfortunately in RHEL as they upgraded
Gnome. Bug for Red Hat is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1294199

Rgds
--
Pierre Ossman Software Development

Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/+CendioThinLinc

[Brian Hinz]

On Wed, Dec 23, 2015 at 2:38 PM, wrote:

Thanks, Brian! That's great news and I'll look forward to the el7 packages.

el7 packages are available now on the nightly builds page (http://tigervnc.bphinz.com/nightly/index.html).

-brian

[family....@gmail.com]

Hi Brian,

I installed the el7 packages on a clean CentOS 7.2 VM this morning. The same thing happens when I try to connect using either tigervnc from my Windows 7 PC or using "vncviewer localhost:2" from the console:

I still get the black screen before the login screen with the "Authentication is required to create a color managed device."

After logging out, the VNC window is not dismissed. I have to manually close it.

As a FYI, the contents of /etc/redhat-release is:
CentOS Linux release 7.2.1511 (Core)
What version did you build the el7 packages on? They made BIG changes between 7.1 and 7.2. For example, GNOME went from 3.8.4 to 3.14.4.

And I'm running kernel 3.10.0-327.3.1.el7.x86_64 in case that matters.

THANKS for the continuing help with this!

Happy New Year to you all!!!

Pat

[Brian Hinz]

On Mon, Dec 28, 2015 at 10:46 AM,  wrote:

As a FYI, the contents of /etc/redhat-release is:
    CentOS Linux release 7.2.1511 (Core)
What version did you build the el7 packages on? They made BIG changes between 7.1 and 7.2. For example, GNOME went from 3.8.4 to 3.14.4.

The build host is fully updated to the latest 7.2.  I did some minimal verification to make sure that Xvnc worked, but I have not tried to replicate your specific configuration yet.

-brian

[Pierre Ossman]

On Mon, 28 Dec 2015 07:46:46 -0800 (PST)
family....@gmail.com wrote:

>
> I still get the black screen before the login screen with the
> "Authentication is required to create a color managed device."
>

This is not an error we can fix. Red Hat/Gnome needs to fix this.

> After logging out, the VNC window is not dismissed. I have to
> manually close it.
>

This is a result of 5d284e72. Reset doesn't work properly in Xvnc so we
were forced to terminate instead. But that caused problems for people
as they didn't expect it to terminate just because the last application
closed.

In your case that's however exactly what you want, as I assume you gave
the -once argument. I'll try to sort out a fix for it. Until then you
can specify -reset on the Xvnc command line.

[Pierre Ossman]

On Tue, 29 Dec 2015 10:46:37 +0100
Pierre Ossman <oss...@cendio.se> wrote:

> On Mon, 28 Dec 2015 07:46:46 -0800 (PST)
> family....@gmail.com wrote:
>
> > After logging out, the VNC window is not dismissed. I have to
> > manually close it.
> >
>
> This is a result of 5d284e72. Reset doesn't work properly in Xvnc so
> we were forced to terminate instead. But that caused problems for
> people as they didn't expect it to terminate just because the last
> application closed.
>
> In your case that's however exactly what you want, as I assume you
> gave the -once argument. I'll try to sort out a fix for it. Until
> then you can specify -reset on the Xvnc command line.
>

Actually, it works anyway. I tested it here on Fedora 23 and it works
just fine.

What does your inetd configuration look like?

[family....@gmail.com]

Thanks, Pierre!

Here is the content of the xinetd file. I use 3 different ports to allow my users to connect at different resolutions depending on their equipment and bandwidth.

Pat

service vnc
{
type = unlisted
disable = no
flags = REUSE
socket_type = stream
port = 5901
wait = no
user = root
protocol = tcp
server = /usr/bin/Xvnc

server_args = -desktop VNC-Remote-Access -inetd -query localhost -once -terminate -depth 16 -geometry 1280x1024 -securitytypes none
log_on_failure += USERID
}

service vnc
{
type = unlisted
disable = no
flags = REUSE
socket_type = stream

port = 5902

wait = no
user = root
protocol = tcp
server = /usr/bin/Xvnc

server_args = -desktop VNC-Remote-Access -inetd -query localhost -once -terminate -depth 16 -geometry 1024x768 -securitytypes none
log_on_failure += USERID
}

service vnc
{
type = unlisted
disable = no
flags = REUSE
socket_type = stream

port = 5903

wait = no
user = root
protocol = tcp
server = /usr/bin/Xvnc

server_args = -desktop VNC-Remote-Access -inetd -query localhost -once -terminate -depth 16 -geometry 1920x1200 -securitytypes none
log_on_failure += USERID
}

[Pierre Ossman]

On Tue, 29 Dec 2015 05:36:16 -0800 (PST)
family....@gmail.com wrote:

> Thanks, Pierre!
>
> Here is the content of the xinetd file. I use 3 different ports to
> allow my users to connect at different resolutions depending on their
> equipment and bandwidth.
>

TigerVNC supports dynamic resolution changes, so you really don't need
different configurations for that.

> server_args = -desktop VNC-Remote-Access -inetd -query
> localhost -once -terminate -depth 16 -geometry 1280x1024
> -securitytypes none

A 16 bit depth is much slower since almost all optimisation is written
for the 24 bit case. I also don't think you really gain much in terms
of bandwidth. Any particular reason you are using that depth?

Still, I tried this configuration and it works just splendidly here.
The server terminates properly when I log out.

I am using xdm though as gdm is segfaulting for me. Could you try with
xdm as well?

[DRC]

On 12/30/15 8:20 AM, Pierre Ossman wrote:
> A 16 bit depth is much slower since almost all optimisation is written
> for the 24 bit case. I also don't think you really gain much in terms
> of bandwidth. Any particular reason you are using that depth?

You gain nothing, actually, in terms of bandwidth if you are using
Tight/JPEG encoding (which is the most optimized encoding, and the
default, in TigerVNC.) This encoding will use solid or mono subencoding
for subrectangles with 1 or 2 colors, 8-bit indexed subencoding for
low-color subrectangles (the breakpoint is generally 24 or 96 colors),
and JPEG for high-color subrectangles. Depth=16 vs. Depth=24 probably
doesn't affect the low-color subrectangles, and for high-color
subrectangles, the 16-bit pixels are converted into 24-bit prior to
compressing as JPEG. Using 16-bit can improve bandwidth with other
encodings, but it's the difference between "bad" and "not quite as bad."
Tight/JPEG is going to deliver the best bandwidth and performance out
of all of them. The others are included just for compatibility.