This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Erik Steffl <steffl@bigfoot.com> To: svlug@svlug.org Subject: Re: [svlug] Evil development trick of the day J C Lawrence wrote: > > On Fri, 21 Sep 2001 19:35:22 -0700 > Erik Steffl <steffl@bigfoot.com> wrote: > > > J C Lawrence wrote: > > > from what I remember it enabled the X client to be disconnected > > from one server and connect to another (so I assume that forced > > disconnect when X server dies would not cause a problem). > > True. > > > another strange solution (I guess you already thought about this > > one): have the vnc server running and use it for everything, have > > the X server only for running vnc client fullscreen. not good for > > graphics intensive work but for bunch of editor sessions you > > wouldn't notice difference (almost). Then you can simply restart X > > after it crashes and connect to the same vnc server. this covers > > all your programs (apart from DRI ones), not only emacs... > > Which doesn't really handle. If X goes on the machine that the VNC > server is running on VNC goes. There's not much net gain there. no, vnc servers is still ok, just client does, which does not influence server (or X clients). it works like this: x-client <-> vnc server <-> vnc viewer <-> X server x-client: it uses vnc server as regular X server, so when you start X as :0 then you start vnc server as e.g. :1, set DISPLAY to :1 and start x-clients. vnc server: provides X services to x-clients and doesn't care about anything else. vnc viewer: connects to vnc server and displays the vnc server's virtual screen and provide an input as well. you can have zero or more vnc viewers connected to one vnc server at one time (they all display the same data). there are various kinds of vnc viewers - there is one for X, for svga, for other platforms... the only program that has connection to the visible X server (the XFree86 server that you have problems with) is vnc viewer. if X dies, the viewer dies but it does not matter much to vnc server. you can just start another viewer. Even if you cannot reset the video card, as long as your networking works you can start vnc viewer on another machine... the x-clients do not see any of this - they are connected to vnc server (which is X server too, but not the visible one). not sure if the above is clear, here's the way to test it: start X server (let's say it's :0) start in background: vncserver& (let's say it's :1, you can either specify it or just let it pick first unused number) - start this with nohup (some shells do it automatically, or based on some settings, or just use nohup command) xterm -display :1 vncviewer :1 (use any of the vnc viewers available, the easiest to use is the x vnc viewer, since you already have X server working) - now you see the vnc server and the xterm on it, possibly some other stuff (depends on how exactly your vnc server is configured, WM might be running etc) now kill your X server (the visible one :0). vnc server :1 and xterm on it are intact (still running). you can start the X server :0 again and start the vnc viewer again and you will see vnc server :1 in exactly the same state you left it in before killing X :0. you can also start vnc viewer on another machine and connect to vnc server :1 (use vncviewer hostname:1) > Running XEmacs -unmapped divorces it from dependence on X. Running > it under screen divorces it from dependency on either X or having a > currently running login on the machine. that's exactly what vnc server does (X dies but vnc server lives). since vnc server does not have any hw dependent code it is very stable (most of the instability of X servers is in code close to hw) [it's not the only reason but I think it's an important one]. I run it on solaris for months at a time and I don't think it ever crashed (it only goes down when machine is rebooted). > Admittedly I could possibly achieve the same effect from a VT via > nohup (haven't tried). not sure about that - can you re-connect to the stdin/stdout of nuhup processes? btw: I was wondering why the disconnect/reconnect functionality is not standard part of X protocol. I mean X is very network oriented how come they didn't think of this? it's the single most annoying (missing) feature of X, IMO. it should have been easy to disconnect any x-client from X server and then, at some point, reconnect it to a X server again. I mean there's no reason for x-client to die just because connection to X server is closed... ===