Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 613528 - net-misc/tigervnc-1.7.1-r2 no longer works with xinetd
Summary: net-misc/tigervnc-1.7.1-r2 no longer works with xinetd
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: otakuto.gentoo
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2017-03-22 11:40 UTC by David Flogeras
Modified: 2021-02-15 05:07 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch from tigervnc github fixing described behaviour (712cf8673d6e57442f41636e44020f5e1839c7f8.patch,1.52 KB, patch)
2017-04-25 16:47 UTC, David Flogeras
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Flogeras 2017-03-22 11:40:29 UTC
I use tigervnc[server] in conjunction with xinetd to fire up a server when someone opens a connection on the specified port.  My xinetd.d service looks like the following

service myvnc
{
  protocol = tcp
  socket_type = stream
  wait = yes
  user = myuser
  server = /usr/bin/Xvnc
  server_args = -geometry 1280x1024 -listen tcp -extension MIT-SHM -inetd -query localhost -once -depth 24 -rfbauth /home/myhome/.vnc/passwd
}

After upgrading to 1.7.1-r2 this no longer works, the Xvnc process just pegs the CPU at 100% and no connection is established.  If I start Xvnc by hand with the command line:

Xvnc -geometry 1280x1024 -listen tcp -extension MIT-SHM -query localhost -once -depth 24 -rfbauth /home/myhome/.vnc/passwd :1

It works as one might expect.  I am seeing this behaviour on both x86_64 and arm.

Reproducible: Always
Comment 1 Matt Turner gentoo-dev 2017-03-27 01:33:38 UTC
Is this a regression in comparison to some other version?
Comment 2 David Flogeras 2017-03-27 16:47:04 UTC
Yes, this works fine with previous versions, most recently =tigervnc-1.7.1, so it has to do with the -r2 patchset I'm guessing.

Also, the -r2 patches say they are so that you can compile against xorg 1.19, but I had no trouble downgrading back to tigervnc-1.7.1, which was compiled against 1.19.  Dunno what that means, but is notable.
Comment 3 David Flogeras 2017-04-25 16:47:31 UTC
Created attachment 470906 [details, diff]
Patch from tigervnc github fixing described behaviour

I trolled tigervnc's Github and found this commit, which fixed my issue.
Comment 4 David Flogeras 2017-04-25 16:48:22 UTC
(In reply to David Flogeras from comment #3)
> Created attachment 470906 [details, diff] [details, diff]
> Patch from tigervnc github fixing described behaviour
> 
> I trolled tigervnc's Github and found this commit, which fixed my issue.

trawled, not trolled.
Comment 5 Alex Dubenetsky 2017-05-08 10:47:21 UTC
I can confirm it, but not only xinetd, also calling via lightdm produce the same bug - 100% cpu load with Xvnc process and nothing. So it is a wider issue.

The patch is helps. Thank you David!

Yes, it's a regression.
Comment 6 Jonas Stein gentoo-dev 2020-01-12 13:42:58 UTC
confirmed by Alex.
otakuto, what is your opinion about the patch?
Is the bug still present in 1.9.0-r1?
Comment 7 David Flogeras 2020-01-12 23:54:10 UTC
Wow, I'd forgotten about this one.  I've been using 1.9.0-r1 on arm and amd64 without patches with no trouble for over a year.  Probably safe to close this as it was integrated upstream.
Comment 8 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2021-02-15 05:07:05 UTC
(In reply to David Flogeras from comment #7)
> Wow, I'd forgotten about this one.  I've been using 1.9.0-r1 on arm and
> amd64 without patches with no trouble for over a year.  Probably safe to
> close this as it was integrated upstream.

Yep, that commit is in all versions of TigerVNC currently in tree.