Red Hat Bugzilla – Bug 67306
Password protected xscreensaver reverts to non password protected setting
Last modified: 2007-04-18 12:43:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Description of problem:
I set my xscreensaver settings to start after 20 minutes and put the monitor in
power saving mode after 20 minutes more, and to be password protected. When I
first start this, everything works as planned, and xscreensaver displays and
works properly. However, after a few hours of the screensaver going on and off
(a seemingly random amount of time), xscreensaver displays, but no longer is
password protected and doesn't turn on power saving mode. The only way to fix
this is to stop the xscreensaver process and restart it. After that, it will
work for a few more hours (or days) and then malfunction again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set xscreensaver for 20 minutes until start, 20 more until power saving mode,
and password protected.
2. Use the computer for a while.
Actual Results: xscreensaver is no longer password protected or in power saving
Expected Results: xscreensaver should have still been password protected and in
power saving mode.
Pentium II 450 MHz
128 MB RAM
256 MB swap space
NVIDIA Riva TNT 16 MB Video Card
Stock Redhat Linux 7.3 "everything" install
All updates applied from Red Hat Network
This sounds like a duplicate of bug 65366.
Please launch xscreensaver like this:
xscreensaver -sync -verbose -no-capture >>& saverlog
then, when the problem happens again, send the relevant portions of the log file
(from just before the last time it successfully locked, to the point after it
unblanked without asking for a password.)
When I launch xscreensaver from the command line, it will never lock, because my
.xscreensaver file doesn't contain the commands to lock. The reason it locks in
the first place is that when xscreensaver is launched from GNOME, it specifies
all of its options on the command line, like this:
xscreensaver -no-splash -timeout 20 -nice 10 -lock-mode -dpms -dpms-standby 40
-dpms-suspend 40 -dpms-poweroff 4
The PID of the process stays the same until the problem occurs, in which case
the PID changes and so does the command:
You see, since it doesn't specify its options on the command line, it reverts
back to the ones in the .xscreensaver file, which are to not lock and not go
into power saving mode.
Perhaps GNOME is relaunching the daemon but not redoing the command line options.
Aha! Then this problem will go away as soon as RH upgrades to the
control-center capplet that comes with xscreensaver 4.x.
In the meantime, a workaround is to have a startup script kill and re-launch
xscreensaver (xscreensaver-command -exit; xscreensaver &) to get it to obey your
An easier workaround is to just run xscreensaver-demo and specify the same
options there as you do on the GNOME screensaver options, therefore putting
those options in the .xscreensaver file. In that way, even when xscreensaver
fritzes out and forgets its command line options, it still uses the same options
specified in the .xscreensaver file.
Xscreensaver is using the 'native' capplet in 4.05-x, in rawhide now, so this
should work. I'm not sure *why* it's getting restarted in your case, though.
This has been fixed for a couple years now. Closing...