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): xscreensaver-3.33-4 How reproducible: Sometimes 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 mode. Expected Results: xscreensaver should have still been password protected and in power saving mode. Additional info: My computer: Pentium II 450 MHz 128 MB RAM 256 MB swap space NVIDIA Riva TNT 16 MB Video Card glibc-2.2.5-34 kernel-2.4.18-5 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: xscreensaver -no-splash 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 settings.
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...