From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401
Description of problem:
The icon of a lock (tied to xscreensaver, I believe) is inactive after an
install of skipjack-2 a.k.a. beta4 - was working in skipjack-1/beta3
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. do install.
2. login to gnome.
3. click on the lock icon.
Actual Results: nothing happens
Expected Results: screen saver to kick in.
if I click on teh preferences for the lock icon, it tells me that XscreenSaver
is not running (but I don't know how it was supposed to
be setup to run in th e1st place).
What version of xscreensaver and control-center do you have installed?
Do you have a ~/.xscreensaver file?
addl info: 2 different systems, fresh install (as opposed to upgrade), existing
/home/<username> acct. both had same problem as described above.
> What version of xscreensaver and control-center do you have installed?
This is a fresh skipjack-2 install. version is what's in 7.2.93
# rpm -qa | grep xscreensav
# rpm -qa | grep control
> Do you have a ~/.xscreensaver file?
ls -l ~/.xscreensaver
-rw-rw-r-- 1 hosler greg 7991 Apr 10 22:21 /home/hosler/.xscreensaver
I'll attach it.
Created attachment 53244 [details]
Are there any errors in ~/.xsession-errors (or on the screen you ran startx from?)
Basically, I can't reproduce this here.
no errors related to .xcreensaver - at least not when I click on the
lock icon. (i tail'ed ~/.xsession-errors, then click on the lock icon, and
nothing gets added. I'll attach the error log, but I do not see anything useful
Since it seems to be the case that xscreensaved is not started, and it seems to
be the case that it is supposed to be started, might I know, please where it
gets started. perhaps I can track down what happens. (I have two different
installations, and it is 100% consistent on both).
correction on the above (was looking at the wrong ~/.xsession-errors
file. When I tail my ~/.xsession-errors and click on the lock icon, I
see the one error added:
xscreensaver-command: no screensaver is running on display :0.0
which confirms that the problem is that either xscreensaver did not get started,
or it died upon initial invocation.
Note that if I restart the deamon (lock -> preferences -> restart deamon), it
Created attachment 53544 [details]
xsession errorlog file
It's supposed to be started by the call to screensaver-properties in
here is some add'l info.
different workstation. 7.2.93 installed.
brand new user - the screensaver works properly.
pre-existing user - the screenserver deamon is not started. The errors in the
.xsession-errors file are these:
xscreensaver-demo: not compiled with --crapplet support
usage: xscreensaver-demo [ -display dpy-string ] [ -prefs ]
(comment: "crapplet" support ?)
I did a grep of screen on ~/.gnome/* and I'm seeing entries in my
.gnome/session file, which I will attach.
Created attachment 53566 [details]
gnome session file
Do pre-existing users have the .xscreensaver file as mentioned above, or do they
have one that claims to be for version 4.01?
What happens if you change the 'Default' session entry to call
'screensaver-properties-capplet' instead of 'xscreensaver-demo'?
not sure. Will have to try. That particular setup is on machine I use M-F
and will try this coming monday.
in the meantime, the other machine that I setup, which also exhibits the
"screen doesn't lock under gnome" problem, has a DIFFERENT .gnome/session file.
This setup is relatively new. I removed the .gnome* hierarchy in one of the
early Hampton beta's, probably beta2, and have not updated/changed since (i.e.
it has "rolled over" from beta2 to beta3 to beta4.
The interesting thing here is that this .gnome/Session file does NOT have any
Xscreensaver in it at all (which possibly might explain why this particular one
doesn't start xscreensaver). This .gnome/session file is attached. Note that I
generally do not run the screen locker on this workstation (at home), so it is
quite possible that the screen locker didn't work in beta2, and I am now finding
out because I inherited a Session file created in beta2.
I might be looking at 2 different problems here. This beta2 session file, and
the other one (created a _LONG_ time ago, but which worked under skipjack1).
*IF* I have 2 different problems here, then the end users won't be seeing the
beta2 session file problem, but some might see the older .gnome/session file
problem that was in the earlier attachment.
Created attachment 53690 [details]
.gnome/session file (created undr Hampton beta2)
Yeah, the beta2 stuff is probably screwed up; it works now in testing here.
Any luck on the other machines?
Does this appear in any final releases?
unable to test - as/when I updated the .gnome/session file, then the problem
OK, going to mark as closed for now. Please reopen if this comes back with new