improve support for tigervnc

Bug #1655795 reported by Vagrant Cascadian
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Epoptes
Fix Released
Undecided
Unassigned

Bug Description

Debian is dropping support for xvnc4viewer (and xtightvnc) in the upcoming stretch release, and tigervnc-viewer appears to be *nearly* compatible with it as a replacement.

The attached patch gets this mostly working, but the xtigervncviewer processes don't response to the kill signal passed in stopTerminal (e.g. client -> broadcasts -> stop broadcasts). They also don't respond to manually killing the pid as root, even with "kill -9"...

the first monitor/assist work fine, but subsequent attempts require exiting the epoptes gui.

Broadcast windowed mode works, but broadcast fullscreen doesn't appear to work.

Using ssvnc might be an alternate option, but has a recommends on "default-jre | java5-runtime" packages, which pulls in quite a few packages, at least in Debian.

Revision history for this message
Vagrant Cascadian (vagrantc) wrote :
Revision history for this message
Fotis Tsamis (ftsamis) wrote :

Thanks for reporting this Vagrant!

Maybe it is a good chance to have a look at gtk-vnc.

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

I've noticed two separate issues, one is that `xtigervncviewer -listen` doesn't accept multiple incoming connections; I reported it in https://github.com/TigerVNC/tigervnc/issues/400.

The other one is that sometimes it doesn't exit cleanly, preventing new viewers from launching. Unfortunately I haven't found a reliable way to reproduce it, it only happens some times.

If upstream accepts those to be bugs, I guess we can recommend tigervnc in epoptes, and leave it up to the tigervnc debian maintainer to backport the fixes to debian stretch?

Revision history for this message
Fotis Tsamis (ftsamis) wrote :

I remembered that gtk-vnc doesn't have listen support, so it's a no go for now.

Main problem for now is the issue that Alkis opened on tigervnc upstream, but I don't think we'll get a fix soon enough there.

Opening multiple listening viewers (one per x11vnc connection) could be a solution, but I'd say we can just go with ssvncviewer which supports listening for multiple connections in one process.

Regarding "the first monitor/assist work fine, but subsequent attempts require exiting the epoptes gui.", this is mostly on our end and it's due to not waiting for the exit status of the vncviewer process in python, which makes it a zombie, and since xtigervncviewer -listen exits after the first connection is gone, we are left with a zombie process right after the first connection. Fix for that is trivial and will be pushed soon.

Revision history for this message
Vagrant Cascadian (vagrantc) wrote :
Changed in epoptes:
status: New → Fix Released
importance: Undecided → Unknown
status: Fix Released → Unknown
importance: Unknown → Undecided
status: Unknown → New
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.