Bug 64920 - Screen savers will not exit
Summary: Screen savers will not exit
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xscreensaver (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-14 15:15 UTC by David Roberts
Modified: 2007-04-18 16:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-09 20:55:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Roberts 2002-05-14 15:15:49 UTC
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:

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

Comment 1 Bill Nottingham 2002-06-12 06:40:50 UTC
What kernel are you running, and what version of pam?

Comment 2 wilburn 2002-06-12 17:33:12 UTC
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   

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.

Comment 3 David Roberts 2002-06-17 22:05:42 UTC
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

Comment 4 wilburn 2002-06-18 22:42:17 UTC
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.

Comment 5 David Roberts 2002-06-19 17:04:27 UTC
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.

Comment 6 wilburn 2002-06-19 17:25:26 UTC
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.

Comment 7 Jamie Zawinski 2002-07-27 06:56:55 UTC
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.

Comment 8 Ray Strode [halfline] 2004-11-09 20:55:02 UTC
This bug appears to be a configuration problem on the users' systems
that are affected.  Closing...

Note You need to log in before you can comment on or make changes to this bug.