Restart RDP and VNC in weston container on errors

Dear Community,

considering this article and this other post as a starting point, I have experimented with remote shared screen with a Torizon 5.1.0 on Colibri iMX8QXP. As mentioned in those two references, remote screen is very helpful for support activities.

It would be great, but the main issue is that often both VNC (TigerVNC) and RDP (Win10 Remote Desktop Connection) clients have some communication errors or disconnection, and the server process is not able to recover and dies logging “unknown child process exited”, without automatically restart. You can see an example with many warnings and the final unrecovered error in the weston log attached.

Therefore the weston container keep on running, but the remote screen server is gone forever.

Are you able to reproduce it? Do you think is something specific to my setup? Do you see any alternative to decouple VNC/RDP server from the weston container to restart it independently if needed?

Thanks in advance and best regards,

ldvp

Greetings @ldvp,

So I was able to recreate the issue by using RDP with Win10 Remote Desktop. VNC was fine however, though I use “TightVNC” on my Windows machine. Furthermore when we originally tested this feature we mostly tested on Linux since it’s what our developers use. Therefore we might’ve not tested the common Windows options as well. Can you try alternative programs like “TightVNC” and see if that is more stable.

I think we need to do some more investigation here as the issues might be related to the program used to connect to VNC/RDP. In any case though it is an issue that the VNC/RDP server doesn’t restart after such an error. Though I’m not sure if it’s necessarily that VNC/RDP is not restarting. For example with my RDP error I can try to connect multiple times, but it disconnects immediately. However it seems some kind of connection was made, because for every attempt made a mouse cursor is left on the display output.

Could you try connecting a keyboard to the device and run ctrl + alt + s and see if this resets/restarts RDC/VNC. Obviously this isn’t really a fix especially if the device can’t be accessed physically but it’s a possible workaround for the moment while we try and analyze the issue on our end.

Best Regards,
Jeremias