Bob, I had a thread with you a while back about the session timing out and closing my connections. I found that by killing xscreensaver the problem went away. The problem started after running a patch bundle in. I have recently discovered that the problem appears to be in my ".xscreensaver" file. I noticed that a new user I created did not experience the same issue. Their sessions never "timed out". I moved their .xscreensaver file over mine and my problem cleared. I have compared the 2 files and do not see any major differences, other than the screensavers I disabled in my file. (Not sure about all that's in the file though)
Might this be a similar issue? Paul Whitener On Tue, 2007-02-20 at 07:01, P.S.M. Swamiji wrote: > I too see that some time xlock screen comes when hotdesking is done, > though it is > not reproduced always. A bug 6241444 exists on this. > > Thanks > P.S.M.Swamiji > > Note:These are my personal opinions, nothing to do with my employer > > Matthias Ernst wrote: > > This time it took a long time before the xlock problem happened again. It > > is indeed the > > xscreensaver which poses the problem: > > > > 0 573 28001 2459 0 0 0 0 Z 0:00 > > <defunct> > > 0 0 2459 1 0 59 20 9520 5336 600103cf7d2 S pts/51 0:14 > > xscreensaver > > > > There is a defunct child process of xscreensaver and after killing > > xscreensaver, > > the xlock took over and I could unlock the screen with the password. So the > > problem is indeed as Bob Doolittle assumed. > > > > The stack trace of the xscreensaver is: > > > > [EMAIL PROTECTED] pstack 2459 > > 2459: xscreensaver -nosplash > > ff341134 pollsys (ffbf9fd0, 1, ffbfa090, 0) > > ff2e2004 pselect (ffbf9fd0, ff36ba68, ffbfa280, 40, ffbfa090, 0) + 1c8 > > ff2e237c select (b, ffbfa180, ffbfa200, ffbfa280, ffbfa314, 0) + a0 > > ff22c3bc _XtWaitForSomething (77720, 0, 0, 0, 0, 1) + 1f4 > > ff22be40 XtAppNextEvent (77720, ffbfa4c8, 1, 0, 7b660, 2) + 1d8 > > 000331a8 passwd_event_loop (ffbfeab0, 63400, 32c00, 7300c, 4, 1) + 248 > > 00038b74 pam_conversation (1, ffbfa650, ffbfe6b8, 48400, 48624, 63400) + > > 298 > > fef35154 do_conv (cba60, 1, 1, ffbfa8b8, ffbfe874, ffbfe6b8) + 110 > > fef35408 __pam_get_authtok (cba60, 1, 6, fedf1020, ffbfe72c, fee0205c) + > > 15c > > fedf0d70 pam_sm_authenticate (cba60, 1, 0, 19, fedf0b38, 0) + 238 > > fef32c80 run_stack (cba60, 1, d4e78, 9, 1, fef48bac) + c8 > > fef32f24 pam_authenticate (cba60, 1, 13224, 15100, 21584, fef48000) + 30 > > 00037d4c pam_passwd_valid_p (e95f8, 48000, 93218, 1, 6356c, 23d) + 304 > > 00017c9c main_loop (ffbfeab0, 380001, 10f118, 63000, 1, ffbfeab4) + 85c > > 00018294 main (0, 42400, 1c200, 19500, 1, 16800) + 364 > > 00015e70 _start (0, 0, 0, 0, 0, 0) + 108 > > > > I will open a service call with Sun today. > > > > Regards, > > > > Matthias > > > > > > Bob Doolittle wrote: > > > >> From previous description, it appears that he had a > >> hung xscreensaver *as well as* an xlock program > >> running. My guess is that it was the xscreensaver > >> that had the grab, so the xlock was actually blameless. > >> > >> If xscreensaver is hung, and doesn't respond to > >> xscreensaver-cmd when it tries to lock it, utxlock > >> will incorrectly conclude that there is no xscreensaver, > >> and will run xlock. I believe this is what is occurring > >> in this case, which is why I asked Matthias to (the > >> next time the problem occurs): > >> - verify that an xscreensaver is running for that display > >> - try xscreensaver-cmd to communicate with it > >> > >> My guess is that xscreensaver-cmd will fail. > >> > >> -Bob > >> > >> Craig Bender wrote: > >> > >>> What I don't understand is why the fallback to xlock is not unlocking. > >>> Granted, it is easy to mess up entering your password using xlock. > >>> > >>> Can you try from non-root account? Just open a terminal window and > >>> type xlock. Click the mouse, and wait. You should be prompted for > >>> your password and it should unlock the screen. > >>> > >>> Matthias Ernst wrote: > >>> > >>>> Bob Doolittle wrote: > >>>> > >>>>> Matthias Ernst wrote: > >>>>> > >>>>>> That sounds like a good explanation. I have reenabled the xlock and > >>>>>> will > >>>>>> wait for the next time the problem occurs and then look in more > >>>>>> detail on > >>>>>> the xscreensaver process. As soon as I have more information, I will > >>>>>> open a service call with Sun and try to get the newest xscreensaver > >>>>>> patch. > >>>>>> > >>>>>> > >>>>> I think this list membership would appreciate you sharing your > >>>>> final conclusions, so folks in future could benefit from > >>>>> your experience. > >>>>> > >>>> Of course I will, but it might take a bit of time. We have a fairly > >>>> small > >>>> installation (about 24 Sunray stations) and the problem happens only > >>>> sometimes > >>>> and to some people. My guess is that it might actually be connected > >>>> to the > >>>> xscreensaver settings of the user. It happened about six times > >>>> during the > >>>> first three weeks of January after upgrading the server to the latest > >>>> Solaris > >>>> 10 release but it has not happened during the last week. So I have to > >>>> wait > >>>> for the next occurence. > >>>> > >>>> But even if it only happens sometimes, if it happens to somebody who was > >>>> running a long Mathematica or Matlab calculation and cannot get to their > >>>> results, people are understandably not very happy. > >>>> > >>>> Regards, > >>>> > >>>> Matthias > >>>> > >>>> > >>> _______________________________________________ > >>> SunRay-Users mailing list > >>> [email protected] > >>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>> > >> _______________________________________________ > >> SunRay-Users mailing list > >> [email protected] > >> http://www.filibeto.org/mailman/listinfo/sunray-users > >> > > > > > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://node1.filibeto.org/mailman/listinfo/sunray-users
