From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 Description of problem: I used the exact same version of xscreensaver in RedHat 7.2 and did not have this problem. I set up the screen saver to cycle every few minutes. None of the client programs exit. They continue to run concurrently. When I unlock the screen, they still run in the background slowing my system down. I have a NeoMagic graphics card in a Thinkpad 240 laptop. This is not tied to cycling screen savers. Even if I limit it to one, that one remains running in background. The screen saver clients will not die with a default kill signal. I must use a kill -9 to kill them. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Log in 2.Leave the system alone long enough for the screen saver to kick in 3.Let it go a few hours, watch the processes stack up Actual Results: Lots of screensaver processes are running at once Expected Results: Only one screensaver client process should run at a time, and none should run after the screen un-blanks. Additional info: It worked in RH-7.2 with the identical version of xscreensaver
What kernel are you running, and what version of pam?
I see this on RH 7.3 with all updates. kernel: 2.4.18-4 pam: 0.75-32 xscreensaver: 3.33-4 I see 3 symptoms: 1. xscreensaver hack processes don't exit when xscreensaver unlocked. Number of hack processes increases with time xscreensaver is active. After running screensaver for about 1 1/2 hours, ps ax | grep root reports: 29211 ? RN 0:00 lmorph -root 29243 ? RN 0:00 blaster -root 29275 ? RN 0:00 bubbles -root 2. With xcsreensaver running, often looks like more than 1 hack running at a time. 3. With xscreensaver not running, occasionally see hack running intermitantly. I have modified /usr/X11R6/lib/X11/app-defaults/XScreenSaver to lock by default: *lock: True I also have a custom /etc/pam.d/xscreensaver. I can give more details, if helpful.
Kernel version 2.4.18-4 pam version 0.75-32 No modifications to the kernel or to pam. XscreenSaver Xdefaults settings were changed to lock by default. Other changes were also made. The same Xdefaults were used in Redhat 7.2 as in 7.3
OK I've found the problem in my case. Definately specific to me, but hopefully this will give hints for others. I have a csh script in /etc/profile.d/ that checks the value of TERM. TERM doesn't exist at the time this script is run during a gdm login and causes an error, which can be seen in .xsession-error. I'm not sure how this affects xcreensaver, but it is very reproducible. Adding a check for the existence of TERM fixes the problem. I suspect the change between 7.2 and 7.3 is when TERM gets defined relative to when the /etc/profile.d/ scripts run.
When I add /etc/profile.d/local.csh with the following line: if (! $?TERM) setenv TERM "" This problem goes away. I don't believe xscreensaver should care about the value of $TERM, so I think it is still a problem in xscreensaver.
From what I see, the problem is not caused by TERM not being set, but by a script that generates an error because TERM is not defined. csh seems to treat most references to an undefined variable as an error, including 'if' statements. I could cause the same problem by trying to use any undefined variable in a /etc/profile.d/ csh script e.g. if ( FOO == whatever ) then endif causes the same problem, assuming FOO is undefined. I don't know why this affects xscreensaver and don't know if it should be considered a bug or just poor scripting on my part.
This is *so* not an xscreensaver bug. By writing a broken init file, you screwed up your shell so badly that exec ("/bin/sh", "-c", "bubbles -root") does not work. You're lucky anything works at all. There's no way for xscreensaver (or anything else) to work around this.
This bug appears to be a configuration problem on the users' systems that are affected. Closing...