[LightDM] Configuring LightDM to not kill my session if VNC disconnects?

[Ronald Hoogenboom]

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
>>