Ronald Hoogenboom
2016-Feb-02 07:19 UTC
[LightDM] Configuring LightDM to not kill my session if VNC disconnects?
Hi Dawn, To achieve what you want (keep X11 programs running after disconnecting from the server and re-connecting to them in a later session), you may want to look at xpra <http://xpra.org>. Regards, Ronald. On 02/01/2016 09:00 PM, lightdm-request at lists.freedesktop.org wrote:> Hi Dawn, > > LightDM uses Xvnc to allow VNC connections. The session is killed when Xvnc > quits, which is the same behaviour if any X server dies. > > Xvnc quits if the TCP/IP connection is dropped, and I'm not currently aware > of it having any feature to allow re-connects (I don't know a lot about > Xvnc, so if someone does know more please let us know). If it did, we could > make use of that. I suspect based on my knowledge of VNC there's no method > of knowing a second TCP/IP connection is from the same user as the first. > > So with the current technology I don't think it's possible, though it's a > very desirable feature from a user perspective. > > --Robert > > > On Sun, 31 Jan 2016 at 19:42 Dawn Mew <dawn at prototeam.org> wrote: > >> Hello! >> >> I'm trying to set up a headless box that I can access via VNC, and then >> proceed to log into normally. >> >> I put the following into my lightdm.conf: >> >> [VNCServer] >> enabled=true >> command=/usr/bin/Xvnc -rfbauth /etc/vncpasswd >> port=5900 >> width=1920 >> height=1080 >> depth=24 >> >> ...And that works perfectly, except for one major problem: If I *ever* >> disconnect from the VNC, for any reason, my session and all running >> programs are immediately killed. Given the fragility of the internet >> (and yes, I'm tunneling over SSH, before anyone mentions VNC insecurity >> over the internet), I could be disconnected involuntarily at any time, >> not to mention the possibility of wanting to keep a program running >> indefinitely in a graphical session. >> >> So, um... how can I configure my system so that my session is locked or >> suspended when VNC disconnects, instead of being completely destroyed >> like that? (And if I can't, could this be considered as a new feature? >> This is a networked remote-access protocol, the idea that it /must/ kill >> everything in the entire session on disconnect would seem to really >> reduce the feature's usefulness and robustness.) >> >> Thank you! >> >> --Dawn >>