michael schuster wrote: > Alan Steinberg wrote: >> Hi Michael. >> >> I have experienced this too. The screensaver gets locked and just >> doesn't come back to give you an unlock prompt. I worked around it by >> logging in remotely to the system running the VNC server, and then >> killing the xscreensaver that was running. The more permanent solution >> would probably be to disable the screensaver in the first place after >> logging into the VNC session. > > I followed Alan's advice and disabled automatic screen locking in the VNC > session. When I returned this morning, all worked well ... now, after a > lunch break, I wanted to open a new window in this VNC session, and got an > error: > >> Xlib: connection to ":1.0" refused by server >> XlibL No protocol specified >> >> Error: Can't open display: :1.0 > > this happens for any X-based application, AFAICT. looking at ps's output, I > can't find a process that started today (MET), so maybe this would have > happened this morning too if I'd tried.
I created a second VNC session and then fooled around with truss a little bit; it seems the difference between the working and non-working version is the existence of /tmp/ssh-xauth-<random-string>/xauth, where <random-string> is the argument to the -xauth option of Xvnc and different for each vnc session, and which exists for the new one and not for the old (non-working) one. interestingly enough, even 'vncserver -kill <new session>' doesn't cause removal of the associated /tmp/ssh-xauth-* directory, so I'd be curious to hear of any experience about similar cases that anybody else may have to share about this (and how to avoid this ...) TIA Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion'