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
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):
Steps to Reproduce:
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.
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.
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
3. With xscreensaver not running, occasionally see hack running intermitantly.
I have modified /usr/X11R6/lib/X11/app-defaults/XScreenSaver to lock by default:
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
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...