TurboVNC server keeps making new "servers" (ie.: :1, :2, :3) .. but why?

[A анонимный]

Hey people and wonderful devs!

So I have been using TurboVNC for a long time but lately, it keeps making the server on new ports. I just launch my TurboVNC server as a user, nothing fancy. On my regular Ubuntu 20.04 LTS server - the TurboVNC is the latest I could grab from the site. 

How I start it?

Again, nothing fancy: "./vncserver -localhost" that's it.

So I start the server and normally, it starts on :5901 - and :1

After a while it made a server on :2

Tried to debug this behavior. Checked .log files, checked "ps ax | grep vnc", nothing.

Today it did a server on :3. And I just can't seem to force it to make it on the :1. Nor I can find out why it keeps making new ports. The server has been restarted many times, it's updated regularly, but I just can't figure out what's causing this. 

Pls help?

Ps.: I love TurboVNC. I really appreciate all the work that went into it.

A

[DRC]

The vncserver script assumes that a potential X display number {n} is
occupied if one or more of the following is true:

- Something is listening on TCP port 6000 + {n}.  This port would be

used if X11 TCP connections were enabled, but the TurboVNC Server does
not enable X11 TCP connections by default.

- Something is listening on TCP port 5900 + {n}.  This port is used for
RFB connections from VNC viewers.

- The file /tmp/.X{n}-lock or the file /tmp/.X11-unix/X{n} exists. 
These files are used by X11 Unix domain socket connections, which are
the default method by which X applications communicate with the TurboVNC
X server.  If the TurboVNC session didn't exit cleanly, then you may

need to run '/opt/TurboVNC/bin/vncserver -kill :{n}' to clean up the
Unix domain socket files for the session.  If those files aren't cleaned
up, then the X display number for that session won't be reused by a new
TurboVNC session.

Also, on Ubuntu 20.04 and other Wayland-equipped distributions, the
local X server will use Display :1 whenever someone logs in, so if you
want to use Display :1 for TurboVNC, make sure you are logged out of the
local X server.

[A анонимный]

Dear DRC!

Thank you for the fast response!

I just realized my mistake I am so sorry. 
It was qemu.

IF you auto-start KVM/qemu guests, they will start consuming VNC-like ports by default. (think they are for spice viewer?)
You can disable this behavior by removing this for each VM, or much easier, just open "/etc/libvirt/qemu.conf" file.

Look for these lines: 

remote_display_port_min
remote_display_port_max

Just change those to a high port that you never use and your problem is solved.

To apply the changes I suppose restarting the service is enough - but in my case I did a full reboot.

(VMs will shut down safely anyway.)

Ps.: And yes, I ran into this in the past, but it's a new host with a new qemu.conf. Hopefully I won't forget - again.

Sorry for opening a discussion-thread only for this and thank you again!
A

--
You received this message because you are subscribed to a topic in the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/turbovnc-users/RZJbcNlpf0A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/60c69aa7-f0db-a092-9b75-e93c52d5f3b4%40virtualgl.org.

[A анонимный]

Dear DRC/mailing list members!

(This is my last message, I am sorry for the spam.)

One more thing.

I checked the function(s) that writes out the error message.

bool CheckDisplayNumber() in turbovnc/unix/Xvnc/programs/Xserver/hw/vnc/init.c (C)

sub CheckDisplayNumber in turbovnc/unix/vncserver.in (perl)

The perl one is fine. The perl script/function seems to print out (via die/warn) the exact error, only the C one "hides it".

I saw that the code actually checks for each problem step-by-step and then returns a FALSE if something goes wrong. (in the C one)
Couldn't you simply modify the code, so it would return a different error code (ie.: the function return from bool to int) and then print an error message accordingly?

I don't know, seems like a not too hard improvement. I, the horrible programmer, I would probably...

- Change the bool CheckDisplayNumber() into an int CheckDisplayNumber() and return a number accordingly.

- Make a char[] GetDisplayNumberError() function that would return a text according to the error number it receives.

- Change the :236 init.c call so if it's not 0 (OK) it should call the new GetDisplayNumberError() function and then print the error cause.

It's just print so it should not bother anyone, nor mess up shell scripts. Of course, it's C, it's char (error msg), so I don't know the security implications. You guys probably have a safe and great way to handle such safety concerns. This way the user would get a verbose message about what happened.

Just an idea, feel free to ignore. 

Thanks for the great software once again!
Have a great week, folks!

[DRC]

The C CheckDisplayNumber() function is only invoked if you run Xvnc in inetd mode, which is not the default.  inetd is not widely used these days because of security concerns, and it is not part of the normal TurboVNC workflow.

You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/CAOx50GXY1QZS7DcZ0JNX5wD9j6mbDE%3DCyK%3D-%3DYUQddXyzhy5dw%40mail.gmail.com.