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! On Sun, May 23, 2021 at 11:40 PM A анонимный <[email protected]> wrote: > 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 > > On Sun, May 23, 2021 at 10:38 PM DRC <[email protected]> wrote: > >> 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. >> >> On 5/23/21 12:17 PM, A анонимный wrote: >> > 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? >> >> -- >> 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 >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/turbovnc-users/60c69aa7-f0db-a092-9b75-e93c52d5f3b4%40virtualgl.org >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/CAOx50GXY1QZS7DcZ0JNX5wD9j6mbDE%3DCyK%3D-%3DYUQddXyzhy5dw%40mail.gmail.com.
