Opened 13 years ago
Closed 13 years ago
#198 closed defect (wontfix)
Can't start NX or VNC session
Reported by: | HellFire | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.12 |
Component: | Server | Keywords: | |
Cc: |
Description (last modified by )
I can't start an NX or VNC session. Can't see why VNC is failing, but NX is failing because of extra data in the DISPLAY var.
VNC server.log: http://kpaste.net/f7e1222
VNC vnc.log: http://kpaste.net/67fa5f
NX server.log: http://kpaste.net/cd2d7
NX nx.log: http://kpaste.net/a99a
NX server is NoMachine
's NX v3.5.0
VNC is RealVNC Enterprise v4.6.3
Change History (4)
comment:1 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Milestone: | → 0.12 |
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → accepted |
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
Apparently LXDE refuses to run multiple sessions. So I guess I'll just have to stay with single windows.
comment:4 Changed 13 years ago by
Resolution: | → wontfix |
---|---|
Status: | accepted → closed |
Looks like there isn't much else we can do about this, feel free to re-open if I have missed anything.
Notes:
- RealVNC support would be "nice-to-have" - contributions welcome.
- Detecting/knowing which sessions refuse to start more than once would also be nice to have, but is probably impossible to implement sanely.
Note: See
TracTickets for help on using
tickets.
RealVNC Enterprise is currently not supported. Although by the looks of things it would be trivial to support, I do not have, nor do I wish to have, a license for this proprietary software.
The lines that would need modifying are in virt/vnc_server_util.py:
These regular expressions are used to detect the state of the VNC server. In your case, it never sees the server reaching "WAITING" state and assumes it has failed after a timeout and kills it.
Until someone adds those missing bits, please try using TigerVNC.
As for NX, this is the only thing that stands out in the logs:
It fires only 4 seconds after the session process starts. This is normally fired by the session wrapper to tell the server that the command that was started in the session has now terminated and that the server can clean it all up.
Does
startlxde
work properly on that system? Does the command return instead of waiting for the session to exit before returning? (as it should)If this does not help, please see session-debugging as the log file containing the reason for the premature exit normally gets cleaned up unless one uses
--no-delete-session-files
.If you can reproduce this problem with a brand new/clean user, on a brand new OS installation, please let me know the details and I will try to reproduce in a virtual machine.