Desktop wont start and vnc or tiger vnc wont show cli or desktop by default #3615
Comments
|
Hi, many thanks for your report. As I see you have 2 issues:
|
|
I have tried via sudo startx and 1.sudo su Login via root also same result |
|
pls can you copy content of |
|
log.txt |
|
How did you install the desktop and did you choose/enable a VC4 OpenGL overlay (e.g. via |
|
Have installed via dietpi-software and raise GPU to 64mb as of now its working via root user for attached display and ip:1 via vnc but for xrdp display(via xvnc) |
|
@krishnasen2401 |
|
Btw great find to disable the Would be actually nice if we could get it running since this would likely reduce overhead and could increase RDP performance. At least it sounds like an overhead to wrap RDP around VNC. |
|
I followed according xrdp I use it in my laptop whereas for other devices like android phone I vnc but for linux system it seems xorg can be port forwarded using ssh will try that I guess |
|
@MichaIng Next to this, xrdp session manager is always trying to use a different port than VNC server is running on. Therefore it's needed to pin VNC server port within xrdp.ini. I did not find a working solution totgehet with session manager until now. |
Ah yes X over SSH is another alternative I used in the past, although only for single X applications, not a whole desktop. But one requires am X server on the client machine then.
Nasty, since both of this was not an issue when I tested it last time. Ongoing issues with XRDP (on Debian) it seems. I was already close to remove it from our software list, only some backported fixes made me stay with it. But if there is now more such need to workaround this or that I'm wondering if it's worth the effort, especially since one can run VNC on the same port (if required to fulfil firewall rules) with much better performance and a large amount clients for all platforms. However the first one is a VNC issue, so these need to be worked around definitely. |
MichaIng
added
Workaround available 🆗
|
I added the workaround for the libunwind8 bug on ARMs, it is an issue on ARMv8 as well: 49f960a I'll run some tests about XRDP default VNC port. This was never necessary before, "-1" simply worked and if there is some auto-detection or socket-based connection behind it, this is actually preferred. |
|
Tested XRDP on VM and was not able to reproduce any issue without changing the Xvnc port option, it connects fine OOTB 🤔. Probably the libunwind8 bug and server crash was the actual reason why port could not be auto-estimated? Could you guys try it with reverting to |
|
ok I did a test on my RPi3B+ as well as VM. First I switched to actual DEV branch. I know you still working on 6.31 but would like to test the fix. RPi3B+ It looks like this now
however this will lead to VNC Server not being able to start. I need to move the workaround down to the line I copied in the forum. I guess it needs to be in front of the executable
This way VNC server is able to start. Next problem is the server port. On my RPi, session manager is trying to connect on
DietPi VM all working fine, VNC Server is running and session manager is going to use correct port 5901 So it makes a difference if you use RPi or VM 🤔 BTW: Will do some test with RealVNC as well to check if the fix is needed there as well. |
|
Fixed LD_PRELOAD: 2039bcf
Very strange, I'll try to replicate on RPi. The annoying thing about it is that default port is 5900 + display number. So we'd need inform user anyway to adjust this together with the VNC display set via dietpi.txt... setting it to 5900 when using shared mode etc... ... ahh and now I see that indeed XRDP tries to connect to display 11: "login successful for display 11" EDIT: There is an RPi build, but it is very outdated and would only be installed on Jessie systems: http://archive.raspberrypi.org/debian/pool/main/x/xrdp/
|
|
Issue confirmed with wrong VNC port chosen by XRDP on RPi. In my case it attempted to connect to display 10 and accordingly port 5910, probably not 11 because its headless and nothing is using display 0? Not sure how exactly derives its choice... |
|
for me it was 10 if VNC server was not running. Not sure how session manager is doing it. But could it be an option to use the variable from |
|
🈴 (12642)(1996301680)[ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied XRDP runs as "xrdp" hence has no access to certs by default. Not sure why it is linked by default at all, however not required and moving a real cert into place (with correct permissions) does not solve anything. Its indeed not the port that is chosen wrong, but the display.
Config files do not allow variables. Of course we can derive the port our self based on dietpi.txt entry and hack it inside xrdp.ini but whenever user changes display or switch to shared desktop mode, it will be broken. So I would prefer to fix the wrong display connection attempt in the first place.
|
|
When setting the port manually to 5901, xrdp seems to behave fundamentally different, here with forced port from service start until successful client connection:
With port set to default
Now lets see how VM/x86_64 behaves... |
|
btw I checked the new fix implementation and it's working for xrdp + tiger vnc. Means vnc server is not crashing anymore on logoff. I guess it would not be needed to start a new VNC session as we already have one running 🤔 EDIT: |
Exactly. A running session started with set screen dimensions on set display index (or local shared session) that the VNC in only "attaching" to and detaching from is what the intention is. Actually I like the way how RealVNC aims it, to have no X session running but start a fresh one for every client connection. We break this somehow be manually starting one with our service for RealVNC as well. But this is another topic to have a closer look by times...
Ah, I thought it is a TigerVNC-only issue, not for RealVNC the fix is not applied. Does it fix things for RealVNC just the same (will test as well)? To apply it for both would be even easier, then we can hardcode it into the service script without variable checks and such. |
|
well, not sure if the same fix could be applied for RealVNC as well. During my test I noticed VNC server crashing as soon as I hit the logoff button before after |
RealVNCIs it really a "crash" or is it probably stopped on purpose? As said XRDP on x86_64
The two concurrent X sessions might be even the issue here, at least worth to try So basically we need to decide how we want it:
Actually the second solution sounds more consequent, so XRDP is just another client connector to the same sessions, making it more lightweight if there is anyway an X session running in the background all the time. We could remove the username input (obsolete, unused, like on VNC login, always root) and create/name our own login method (still Xvnc of course) on the top of the list. Downside is, similar to our VNC implementation, that one always attaches to a root user desktop session, no other user login possible. For this one would need to switch to a different login method and at best disable our vncserver service to avoid doubled session. The way TigerVNC is invoked, it blocks logouts btw, to avoid the X/VNC session from closing. Otherwise one would need to restart it manually. On RealVNC this seems to be not the case which @Joulinar might be the issue you face? Do you actually logout or just close the VNC/RDP client? Probably RealVNC has some auto-logout/session-close feature that could be disabled to align it with TigerVNC. Actually I like ondemand session spawning like XRDP and RealVNC by default do it. Will check if there is any such possibility with TigerVNC and test a bid. However this is likely something for next release as I want to finish v6.31 before Juli. |
|
Loooooooool, same error with XRDP when starting Xvnc then with VNC directly... Same solution with preloading to override libunwind... |
|
Actually instead of hacking the LD_PRELOAD into all services, what we need is applying it for the Xvnc (Xtigervnc) binary directly. I cannot find a way to achieve this currently... ... This has the same effect as having the This program also allows to remove libunwind from the list, but this breaks execution as there are other functions of it called which are not provided by libgcc_s or others. So without recompiling, reordering the loaded libraries is the only change. Will patch this inside. |
|
I just verified that XRDP does not support RealVNC:
Checked and verified that RealVNC auto-spawn of X sessions is an enterprise feature, not available by default and likely only working in combination with RealVNC client:
So basically there is no point for us to enable this service. When users do/have an enterprise subscription they'll know what to do. The |
|
Final fix and better RealVNC integration: f96ad09 Whether to have XRDP by default connecting to a running virtual VNC session or spawning an own one is a matter of future discussion. For now at least things are running again as before (in case of RealVNC slightly better). |
|
Well done Micha. Quite a lot of time spent on such a small bug. |
|
Part of the time I took the chance to have closer look on some other things I was never really happy with on our VNC integration. Still much to do and decisions to make until I am 100% satisfied on it 😅, but many things about how both VNC servers and XRDP work, what's possible and what's not, became clear today. Best basis for further tuning at a later time 😃. Updated online docs: https://dietpi.com/phpbb/viewtopic.php?p=4149#p4149 |
+ CHANGELOG | XRDP: The TigerVNC bug affected as well XRDP connections which have been resolved in the same turn: #3615 (comment)
|
Patch has been merged into Debian Buster branch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932499 |
MichaIng
added
Solution available 🥂
Creating a bug report/issue
Required Information
Additional Information (if applicable)
Steps to reproduce
Expected behaviour
Should Display a Desktop Environment may it be lxde or mate
Actual behaviour
Also in vncview unless i give address as ip:1 it wont be displayed same with windows rdp server just a bluescreen
The text was updated successfully, but these errors were encountered: