Bug 429966 - startkde becomes Zombie Child of gdm-binary on logout
Summary: startkde becomes Zombie Child of gdm-binary on logout
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase
Version: 8
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-01-24 00:32 UTC by Peter Gückel
Modified: 2013-01-21 20:22 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-09 07:37:15 UTC
Type: ---

Attachments (Terms of Use)
gdm syslog + gdb + strace output (52.68 KB, text/plain)
2008-03-05 03:43 UTC, Ian Donaldson
no flags Details
/var/log/messages with gdm debug info (7.84 KB, text/plain)
2008-04-20 22:18 UTC, David Benjamin
no flags Details
Section of log file when KDE logout fails (7.51 KB, text/plain)
2008-05-20 13:38 UTC, Markku Kolkka
no flags Details

Description Peter Gückel 2008-01-24 00:32:39 UTC
Description of problem:

When logging out of a KDE session, one is given the choices: log out, restart
computer, and turn off computer. All 3 of these responses cause the KDE session
to be only partially logged out. A black screen appears through the course of
the logging out process, but the mouse cursor remains on the screen, still
movable and functional (albeit without a context menu). There is no way to get
back to that KDE session, nor can one get to gdm. One is in limbo. One has 2
options: either kill X with ctrl-alt-backspace, or open a virtual terminal. In
both of these cases, one must log in and run shutdown -h now. Startkde is a
zombie child of gdm and hence, gdm does not run. Manually running gdm-restart
will verily restart gdm, but upon logging in and out, the aforementioned problem

Version-Release number of selected component (if applicable):


How reproducible:

Log out of a KDE session.

Steps to Reproduce:
1. Turn on computer
2. Log into a KDE session
3. Log out of a KDE session
4. Voilà!
Actual results:

As described above.

Expected results:

KDE sessions should be able to transition smoothly to gdm upon logout and not
leave the user hanging with a black screen, forcing a command line workaround.

Additional info:

I believe it has been covered in totality.

Comment 1 Rex Dieter 2008-01-24 02:53:21 UTC
Can you try an experiment?  Switch to using kdm instead of gdm.  
Edit /etc/sysconfig/desktop to contain:

And restart.  Does the problem remain?

Comment 2 Peter Gückel 2008-01-24 04:12:57 UTC
I haven't been able to get KDM to work since fedora 6. I noticed that you didn't
include the quotation marks around KDE and that clued me in to something:


Yes, KDM works just fine (it won't with KDE). I would never have discovered the
GDM problem, if I hadn't mistakenly exchanged KDE for KDM and been forced to use

But this still means that GDM doesn't work (except about 5-10% of the time -
seems like if I click my response immediately, or if I wait too long, it
definitely won't work, but if I wait just a little bit, but not too long, it
sometimes works, but I haven't been able to determine exactly how long is the
right duration - makes me think that some program might still be running that
doesn't get shut down, but I wouldn't have a clue how to determine whether this
really is the case or not).

Comment 3 Rex Dieter 2008-01-24 04:25:07 UTC
I can assure you that the correct value to use is "KDE" (and quotes don't really
matter), take a closer look at /etc/X11/prefdm for the gory details. :)

I'm sorry too, to hear that you haven't been able to get kdm to work for quite
awhile.  I'd be interested in helping you sort that out (outside of bz, either
via email or irc ?).

Wrt the problem at hand, I've only got f7 boxes and rawhide on my laptop, so
I'll see about (re)installing f8 somewhere to see if I can reproduce it.  If all
else fails, we may have to pull in some expertise from the gdm maintainer.

Comment 4 Peter Gückel 2008-01-24 04:25:47 UTC
Wups! I guess I got excited too soon. It worked twice, then I wrote the last
message and logged out. It failed in the same way that GDM does, just hanging
there with the mouse pointer still active. I rebooted, logged out and all was
fine and now I am writing this. 3 out of 4 successes is better than what I have
been having with GDM, but that is likely just coincidence.

There is something other than KDM/GDM amiss.

Comment 5 Peter Gückel 2008-01-24 04:27:23 UTC
OK, I will switch it back to KDE and see what happens. Back in about 5.

Comment 6 Peter Gückel 2008-01-24 04:37:02 UTC
Something is very strange here. I changed it to DISPLAYMANAGER="KDE" and
rebooted and KDM does not start. I am presented with a command line login and
have to run startx to get to a graphical display (inhospitable gnome,
unfortunately, where I am now). With KDM, KDM verily runs and logs me in, as it

On this computer, KDM will not run when I have the line read KDE (I left the
quotes in). Strange!

Also, another guy from the fedora-list reproduced the problem on his computer
and provided this output:

#ps ax | grep Z
 5723 ?        Zs     0:00 [startkde] <defunct>
Pstree shows that startkde is a child of gdm-binary:

     |        `-{auditd}
     |                         `-startkde

So it is not just my setup.

Comment 7 Peter Gückel 2008-01-24 04:41:49 UTC
Something is very strange here. I changed it to DISPLAYMANAGER="KDE" and
rebooted and KDM does not start. I am presented with a command line login and
have to run startx to get to a graphical display (inhospitable gnome,
unfortunately, where I am now). With KDM, KDM verily runs and logs me in, as it

On this computer, KDM will not run when I have the line read KDE (I left the
quotes in). Strange!

Also, another guy from the fedora-list reproduced the problem on his computer
and provided this output:

#ps ax | grep Z
 5723 ?        Zs     0:00 [startkde] <defunct>
Pstree shows that startkde is a child of gdm-binary:

     |        `-{auditd}
     |                         `-startkde

So it is not just my setup.

Comment 8 Tim Leger 2008-01-24 04:44:43 UTC
Since it hasn't been mentioned yet, this also happens on updated Fedora 7 x86_64
machines.  I've also tried switching to KDM, but I still get the same problem. 
It doesn't happen all the time, more like 1 out of every 5 logouts, but it's
definitely something with KDE.  If I switch to using gnome as my desktop, it
works just fine (both with GDM and KDM).  This problem started on my machines
after an update to kdebase back in November, if that helps narrow down the bug any.

Comment 9 Peter Gückel 2008-01-24 04:50:36 UTC
[Oops! I hit refresh and the last post got posted again.]

Very strange. I looked at the file /etc/X11/prefdm and it does say KDE, but
putting KDE into sysconfig/desktop causes KDM not to run. Yet, when I put KDM in
there, it runs! Perhaps this points to a small programming error somewhere?

Nevertheless, the bottom line is that neither GDM nor KDM work properly with
KDE, but work fine with Gnome.

Comment 10 Ray 2008-01-24 17:16:31 UTC
Hi, I'm having a similar problem and I thougt I'd add my experiences.

I just updated from FC6 to FC7 to FC8 via yum.  I've run KDM regularly as far 
back as I can remember and it's always been fine (and yes, it's "KDE").

On boot, KDM comes up fine and I can login (to KDE, of course).  When I logout 
however, it hangs.  I get a black screen (with mouse working) and after about 
20 or 30 seconds it switches to a console (tty1 I think).

I see kdm running but nothing with 'kde' in its name.  I tried killing kdm from 
the console, thinking that init will restart it.  I get a black screen for a 
few seconds and then back to the console.  If I then hit ctrl-alt-f7 the system 
freezes hard.

I also tried ctrl-alt-backspace during the blank screen following the logout 
but this had no effect except to get me a console more quickly.

I also tried running "telinit 3; telinit 5" from the console but this wasn't 
much different than killing kdm.

Gnome can logout out just fine (when likewise launched from kdm).


Comment 11 Ian Chapman 2008-01-25 20:46:43 UTC
(In reply to comment #8)
> Since it hasn't been mentioned yet, this also happens on updated Fedora 7 x86_64
> machines.

And FWIW this also occurs very regularly on our 120+ F7 i386 desktops but I
haven't seen a particular pattern as to what triggers it. It seems quite
arbitrary. I'll see if I can dig up more information. The machines automount
their homespace over NFS with the automounter maps help in an LDAP server. The
accounts are also not local but held in the LDAP tree. Jic this might have any

Comment 12 Rex Dieter 2008-01-25 21:07:48 UTC
Now I need to chime in... this isn't happening *everywhere*.  We also have quite
a large deployment of F7 i386 boxes (~150), using kdm+kde primarily, NFS'd
automounted homedirs, not a single instance of seeing this. ??  

Wait, most of these boxes are running selinux/permissive.  How about everyone
else?  Seeing any selinux-related denials in logs?  Willing to test if setting
this permissive helps?

Comment 13 Ray 2008-01-25 21:57:48 UTC
A little more info on my circmstances:

I'm just running a single box (laptop), no nfs or anything, and I have selinux 
disabled via a kernel arg (selinux=0).  I don't see any selinux-related errors 
in the logs but I do see a message at boot saying "can't mount /selinux as 
selinuxfs" (I googled it though and it's supposed to be okay/ignorable).


Comment 14 Peter Gückel 2008-01-25 23:58:38 UTC
You are likely right, Rex! I have 2 computers and on the other computer, because
of Dan Walsh's inability to fix lircmd, I had to disable selinux and gdm works
just fine on that machine.

On this machine, I don't have a remote, so I have selinux enabled and I have the
kdm/gdm problem.

I will test in a second by disabling it.

Comment 15 Peter Gückel 2008-01-26 00:37:48 UTC
I completed some testing, with many log outs and reboots.

SELinux is definitely PART of the problem. With SELinux in permissive (no longer
enforcing) mode, both GDM and KDM log out properly. There is no hanging black
screen with a mouse pointer.

However, KDM only runs when the line in sysconfig/desktop reads KDM. It does not
run when the line reads KDE. In this latter case, there is only a command line
login prompt and the user must type startx.

Comment 16 Tim Leger 2008-01-26 01:25:43 UTC
Kwhiskerz, how are setting SELinux (kernel argument or SELinux config file)? 
I've set SELinux on my boxes to disable under the /etc/selinux/config file and
even after rebooting, I still occasionally get the black screen with just the
active mouse pointer after logging out of KDE (regardless if I'm using KDM or
GDM).  As with Ian, my systems automout user home directories from a file server
which is also managing user logins via Fedora Directory Services(Ldap).  I've
also disabled SELinux on the file/ldap server just in case that was causing the
problem, but it made no difference.  From what I can tell, this all started with
the kdebase update back in November (which also caused me to have to mount user
home directories with automount instead of /etc/fstab entry).  As stated before,
my systems are running Fedora 7 x86_64 with the latest updates.

Comment 17 Rex Dieter 2008-01-26 01:32:16 UTC
Anybody experiencing this problem using kdelibs/kdebase from updates-testing? 
If not, please update, and confirm problem still exists.

kwhiskerz, Re: DISPLAYMANAGER=KDE vs KDM, that's separate to the issue at hand,
please file a separate report (I still can't fathom how that's the case, but
stranger things have happened).

Comment 18 Peter Gückel 2008-01-26 05:08:32 UTC
I have updates-testing enabled. The most recent packages (installed) I have
received are:

> rpm -q kdelibs kdebase

I set selinux using the SELinux Management tool. It was always on enforcing, but
this evening I put it to permissive for system default and rebooted. From that
point on, gdm worked, as did kdm, although the latter only with the false
information in sysconfig/desktop. Go figure. Actually, I cannot swear that it is
kdm that is running, as the theme looks identical to gdm, so for all I know, kdm
never runs and it is always gdm. I guess I could turn themes off to see for sure.

I admit that I am content to use gdm (I read that kdm might be phased out in
fedora 9 anyway, due to redundancy, and I concede, so it might not be worth the
effort - what does Rex say?), but it would be nice to have selinux enabled,
despite the many problems it still continues to produce (doesn't allow the
/usr/bin/Xorg to use the lircmd mouse, for example, and now this gdm/kdm logout

Comment 19 Kevin Kofler 2008-01-26 07:11:31 UTC
Stop the baseless rumors, KDM is *NOT* being phased out in Fedora 9, and in 
fact, at least among the people actually maintaining KDM in Fedora, there are 
*NO* plans to phase out KDM. Ever.

Comment 20 Ian Chapman 2008-01-27 12:00:38 UTC
(In reply to comment #12)

> Wait, most of these boxes are running selinux/permissive.  How about everyone
> else?  Seeing any selinux-related denials in logs?  Willing to test if setting
> this permissive helps?

In our case we're running with selinux disabled in /etc/sysconfig, as other's
have posted it started occurring around end of October start of November. I'd
assumed we were having LDAP issues somewhere until I saw a posting with
identical symptoms on the ML. Our gdm config is modified to disable the face
browser so that it doesn't try and pull thousands of user accounts from the LDAP
tree as well as allowing XDCMP for windows users running Exceed. So is anyone
experiencing the problem with the vanilla gdm configuration?

Comment 21 Ray 2008-01-27 19:05:42 UTC
I also have the user list disabled (on kdm).  I just re-enabled it and tested 
but it still hangs.  I thought we might have been on to something (then again, 
kdm and gdm may have two completely different issues; but it seems like too big 
a coincidence).

I noticed that xfs fails to shutdown when I shut the system down.  I wonder if 
this may be part of the problem?


Comment 22 Ray 2008-01-27 19:44:03 UTC
Okay, I think I just confirmed that xfs is the problem (at least on my system 
with kdm).  Those of you having the problem with gdm should check on this as it 
seems like a good candidate for a common cause.

First, xfs starts okay during the system boot.

I login to kde and then logout, reproducing the hanging kdm problem.  When I 
get to a console I check for xfs and it is not running.  I restart it (with /
etc/init.d/xfs restart) and it comes back.  If I try to go back to kdm 
immdiately (ctrl-alt-f7) it freezes the system, like before.  If I kill the 
hung kdm however, init (presumably) restarts it and kdm returns and I can log 
back in.

If I check on xfs while logged in to kde, I see that it's not running.  If I 
restart it and then logout, kdm comes back just fine.

So, it seems that xfs is likely dying during the login process and that kdm is 
hanging on the dead xfs when it tries to come back after logging out of the 

Now to find out why xfs is dying...


Comment 23 Peter Gückel 2008-01-27 19:57:00 UTC
I just updated my system. A couple of kde packages were installed, along with
kde-settings-kdm-3.5-36.fc8.1, I do believe.

I put the correct info (KDE, not KDM) into sysconfig/desktop and rebooted.

There is no mistaking that I am now running kdm, as the theme is entirely
different. I logged out and in again and also rebooted. It seems to work perfectly.

The only thing I have not tested is whether selinux still blocks gdm/kdm from
running. I guess I could give that a try in a bit.

Bravo! Even if selinux is still messed up, kdm is no longer.

Comment 24 Peter Gückel 2008-01-27 20:13:41 UTC

As far as I can determine, kdm/gdm only work properly when selinux is in
permissive, but not in enforcing, mode. I had the hanging black screen again as
I put it into enforcing. Then, I returned to permissive and rebooted and now
everythig worked without a hitch.

Comment 25 Rex Dieter 2008-01-27 20:40:58 UTC
OK, let's keep focused here on the original problem, which seems now to be
related to xfs dieing (reassigning).  Any/all other issues, please report separtely.

Comment 26 Rex Dieter 2008-01-27 20:42:12 UTC
xfs is dieing (reassigning, for real this time).

Comment 27 Ray 2008-01-27 21:30:17 UTC
I dug this out of my logs:

Jan 27 14:31:17 lapdog kdm[2180]: X server for display :0 terminated 
Jan 27 14:31:17 lapdog kdm[2180]: Unable to fire up local display :0; disabling.
Fatal server error:
could not open default font 'fixed'

The kdm messages match my earlier test in time and sequence.
I presume the failure to open 'fixed' font is due to a dead xfs.

I don't see any messages from xfs.  I tried reconfiguring it with an "error-
file".  The error file was created but it's empty after xfs dies.


Comment 28 Ray 2008-01-27 23:02:22 UTC
I did some additional testing running xfs under strace.  I didn't get much out 
of it though.  The strace log ends with this, which seems slightly odd:

17:35:24.019458 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
17:35:24.019554 gettid()                = 7634
17:35:24.019630 tgkill(7634, 7634, SIGABRT) = 0
17:35:24.019708 --- SIGABRT (Aborted) @ 0 (0) ---
17:35:24.020531 +++ killed by SIGABRT +++

That sorta looks like xfs is killing itself.  Of course, there's no indication 
why it would do so.

There wasn't anything else in the log that looked suspicious.

The only other thing I noticed is that xfs appears to be dying around the time 
that kde finishes restoring the desktop session.  xfs is running while kdm is 
up and is still running when I login and when the kde desktop appears.  xfs 
seems to die about the time that my last session member is restarted.  (My 
laptop is rather slow and I have a bunch of session stuff; so the session takes 
quite long to restore.)

I'm taking a break for now.  Maybe someone else can take this farther.


Comment 29 Tim Leger 2008-02-09 06:30:30 UTC
Just wanting to know if there is any progress on resolving this problem.  I've
been keeping up with the updates for my systems (F7 x86_64) and this problem
still remains.  I have SElinux set to disabled and my current kdebase is
3.5.8-31.fc7.  I'm also using GDM at the moment, but switching to KDM has no
effects, this problem is still randomly occuring (about 1 out of every 6 logouts
gets stuck).  For these systems, user directories are automounted from a
fileserver, which also handles user logins via ldap.

  In case it helps, here's what I see on one of the machines after this happens
(to user tleger, i.e. myself) by logging in remotely as another user and
switching to root: 

root      2284     1  0 Feb08 ?        00:00:00 /usr/sbin/gdm-binary -nodaemon
root      2328  2258  0 Feb08 ?        00:00:00 /usr/bin/perl //.swatch_script.2258
root      2346  2328  0 Feb08 ?        00:00:00 /usr/bin/tail --follow=name
--lines=3 /var/log/messages
tleger    2369  2284  0 Feb08 ?        00:00:00 /usr/sbin/gdm-binary -nodaemon
root      2370  2369  0 Feb08 tty7     00:00:07 /usr/bin/Xorg :0 -br -audit 0
-auth /var/gdm/:0.Xauth -nolisten tcp vt7
root      2414     2  0 Feb08 ?        00:00:00 [lockd]
tleger    2415  2369  0 Feb08 ?        00:00:00 [startkde] <defunct>
tleger    2522     1  0 Feb08 ?        00:00:00 /usr/bin/ssh-agent
/usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
tleger    2525     1  0 Feb08 ?        00:00:00 /usr/bin/dbus-launch
--exit-with-session /usr/bin/startkde
tleger    2526     1  0 Feb08 ?        00:00:00 /bin/dbus-daemon --fork
--print-pid 4 --print-address 8 --session
tleger    2692     1  0 Feb08 ?        00:00:12 /usr/bin/python -E
/usr/bin/sealert -s
root      5360  1952  0 00:39 ?        00:00:00 in.rlogind
root      5361  5360  0 00:39 ?        00:00:00 login -- root                  
root      5362  5361  0 00:39 pts/1    00:00:00 -bash
root      5401  5362  0 00:40 pts/1    00:00:00 ps -ef

I checked and xfs is still running, so I don't think that's my problem...

[root@wilbur21 ~]# /etc/init.d/xfs status
xfs (pid 2101) is running...

If I go onto the file server and look in my directory as root, I have a 
.xsession-errors file with the following in it:

localuser:tleger being added to access control list
xset:  bad font path element (#362), possible causes are:
    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax
startkde: Starting up...
kbuildsycoca running...
DCOP Cleaning up dead connections.
kbuildsycoca running...
Reusing existing ksycoca
DCOP Cleaning up dead connections.
winscard_clnt.c:3349:SCardCheckDaemonAvailability() PCSC Not Running
Unable to connect to yum-updatesd.  Please ensure that the yum-updatesd
package is installed and that the service is running.
QLayout "unnamed" added to QVBox "unnamed", which already has a layout
QLayout: Adding KToolBar/mainToolBar (child of QVBox/unnamed) to layout for
QObject::connect: Incompatible sender/receiver arguments
        StarManager::ratingsColorsChanged() -->
ContextBrowser::ratingOrScoreOrLabelsChanged(const QString&)
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  7
  Minor opcode:  0
  Resource id:  0xc00007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  6
  Minor opcode:  0
  Resource id:  0xc00007
QObject::disconnect: Unexpected null parameter
QObject::connect: Cannot connect (null)::activePartChanged( KParts::Part * ) to
KHTMLPart::slotActiveFrameChanged( KParts::Part * )
startkde: Shutting down...
klauncher: Exiting on signal 1
startkde: Running shutdown scripts...
startkde: Done.

Hopefully this helps, please let me know if contents from other log files would
help track down and kill this pesky bug.  This has been driving me nuts since
the kdebase update in November and along with the recent livna nvidia package
mess, I'm beginning to view updates as a very expensive gamble (what little will
I gain vs. what major things will get broken).  

Comment 30 Kevin Kofler 2008-02-09 06:40:57 UTC
Maybe your /etc/X11/fs/config (the xfs config file) is corrupt?

Comment 31 Tim Leger 2008-02-09 07:18:14 UTC
Hi Kevin,

  Well, it doesn't look corrupt, here's the contents of it:

# xfs font server configuration file
# allow a max of 10 clients to connect to this font server
client-limit = 10
# when a font server reaches its limit, start up a new one
clone-self = on
# alternate font servers for clients to use
#alternate-servers = foo:7101,bar:7102
# where to look for fonts
catalogue = /usr/share/X11/fonts/misc:unscaled,
# in 12 points, decipoints
default-point-size = 120
# 75 x 75 and 100 x 100
default-resolutions = 75,75,100,100
# use lazy loading on 16 bit fonts
deferglyphs = 16
# Log errors via syslog.
use-syslog = on
# For security, don't listen to TCP ports by default.
no-listen = tcp

Any other ideas?  I have a hard time believing I'm the only one who still has
this problem with KDE logouts and gdm/kdm.

Comment 32 mb 2008-02-23 23:45:42 UTC
I'm seeing the identical symptoms -- logging out of KDE session with "End
Current Session" will hang the session one time in 5.

The screen is black, but the mouse pointer remains.  I have to ctrl + alt + F6,
login, and /sbin/shutdown -r.

This is happening on 3 different systems, each of which has SELinux disabled,
and no automount or ldap logins.

Not sure if previous comments about XFS refer to the filesystem or the font
server, but I am running the XFS filesystem for /home and ext3 for /.

Here are the KDE processes running while one of the sessions is hung -- check
out user dcb:

[root@localhost xinit]# ps -Af | grep kde
mb   16624  2436  0 12:31 ?        00:00:00 /bin/sh /usr/bin/startkde
mb   16749     1  0 12:31 ?        00:00:00 start_kdeinit --new-startup
mb   16750     1  0 12:31 ?        00:00:00 kdeinit Running...              
mb   16755 16750  0 12:31 ?        00:00:00 klauncher [kdeinit] --new-startup
mb   16757     1  0 12:31 ?        00:00:02 kded --new-startup
mb   16767     1  0 12:31 ?        00:00:05 kdesktop
mb   16873     1  0 12:32 ?        00:00:04 knotify [kdeinit]               
mb   20664 16750  0 13:20 ?        00:00:00 kio_file [kdeinit] file
dcb   20850 20826  0 13:26 ?        00:00:00 [startkde] <defunct>
root     21987 21840  0 15:40 pts/1    00:00:00 grep kde

[root@localhost xinit]# ps 20826
20826 ?        S      0:00 /usr/sbin/gdm-binary -nodaemon

Seems like a serious problem, shouldn't it be a higher priority than 'low'?

Comment 33 Rex Dieter 2008-02-24 01:12:11 UTC
Re: comment #31
Tim, in this context xfs = X Font Server

Comment 34 Rex Dieter 2008-02-24 01:14:43 UTC
Another suspicion I have is that some font metadata is invalid and/or corrupted,
and when folks (re)start xfs it forces a regeneration of the fonts.{dir,scale} data.

Comment 35 mb 2008-02-24 01:39:42 UTC
One additional clarifying point -- I'm seeing this on three systems installed
fresh from the i386 DVD in the last two weeks, and current with all updates.

I didn't follow the posts about KDM/KDE/GDM, is there a known workaround?

Comment 36 Rex Dieter 2008-02-24 02:44:09 UTC
To date, neither I or any KDE-SIG member (that I'm aware of) has seen this or
been able to reproduce.  I (and @ the site I admin ~150 f7/8 boxes) use kdm/kde
exclusively, and have never seen this.

Clearly, currently not much is known to understand the cause, much less diagnose
to fix or provide any workarounds.  Any additional insight, debugging, advice,
mojo, luck, to help here would be greatly appreciated.

The more I think about it, the less likely it appears to have anything to do
with xfs (esp since xfs is disabled by default on f8).  I'll reassign this back
to kdebase, for now.

Comment 37 mb 2008-02-24 05:45:41 UTC
(In reply to comment #36)

> Clearly, currently not much is known to understand the cause, much less diagnose
> to fix or provide any workarounds.  Any additional insight, debugging, advice,
> mojo, luck, to help here would be greatly appreciated.

On the off chance there might be any connection to zombied startkde when logging
out, here are 2 other KDE issues that I'm having on these machines:

1. Attempting to enter Administrator Mode in Control Center apps (for example,
Samba, Service Discovery, Printers) fails, and crashes the Control Center.

2. No mouse cursor themes appear, except "System Theme" and "No Theme".  The old
familiar "Bluecurve" and "Clearlooks" that I had in F7 don't appear.

Comment 38 Kevin Kofler 2008-02-24 17:59:04 UTC
Please keep this at 1 issue per bug report!
Your 1. is probably Bug 434624, please add any additional information you have 
For your 2., that's not a bug, Bluecurve is no longer installed by default, the 
Bluecurve cursors are in bluecurve-icon-theme (along with the icon theme). 
Other parts of Bluecurve are in other bluecurve-* packages.

Comment 39 Ray 2008-02-24 22:46:10 UTC
The work around for the xfs bug that I'm experiencing is to re-start xfs before 
logging out.  I've also noticed that some applications won't run with a dead 
xfs.  (I think kdbg was one.)  Restarting xfs fixes this too.  To restart xfs, 
run the following command as root:

  /etc/init.d/xfs restart


Comment 40 Tim Leger 2008-02-24 23:44:49 UTC
   OK, that may work for those who are experiencing this problem caused by xfs
dieing, but in my case xfs is still running when starkde becomes defunct upon
logout of KDE (please see my earlier posts).  Another observation I've had with
the 24 machines I'm administering (F7 x86_64) is that some of the machines tend
to be more prone to this than others.  Even though all 24 are the same build,
patch level, etc., some tend to do this every time a user logs out of KDE and
other it rarely happens to, even with the same users. 
   As I and several other has posted here, this all started with the kdebase
update last November.  My thinking is the cause of this problem is something
that was changed in that update, what exactly it was I don't know.  In addition,
I also believe this is a KDE issue (not just a Fedora issue) as I have seen this
 same "condition" reported in the kubuntu and gentoo forums as well.   In those
forums, the problem was traced back to KDE not being completely rebuilt after
certain patches.  Apparently if only part of KDE is rebuilt after a major patch,
for example kdebase and kdelibs only, then this same "condition" is reproduced.
 I'm not saying that this is the problem, just a possibility based on what I've
seen on web.
   Lastly, I'm wondering if switching to KDE4 will fix this problem and along
those lines, is KDE4 out of the "buggy" state yet and can one easily install it
via yum to Fedora7?

Comment 41 Ray 2008-02-25 00:15:10 UTC
> OK, that may work for those who are experiencing this problem caused by xfs

Yes, as I said.

> in my case xfs is still running when starkde becomes defunct upon
logout of KDE

Are you sure it's running and not just hung?

> I also believe this is a KDE issue (not just a Fedora issue) as I have seen 
this  same "condition" reported in the kubuntu and gentoo forums as well

Could be.  Could also be xorg (especially if xfs is involved).

> the problem was traced back to KDE not being completely rebuilt after
certain patches

That could certainly cause some serious problems.  However, this bug report, 
AFAIK, is related to F8.  That's what I'm running and where I'm seeing my 
problems and I have no evidence to implicate KDE at this point, only xorg/xfs.  
IIUYC, you're running F7?  So you're issue is likely to be unrelated to mine or 
the other reports herein.


Comment 42 Tim Leger 2008-02-25 02:16:25 UTC
Ray, from one of my previous post:

[root@wilbur21 ~]# /etc/init.d/xfs status
xfs (pid 2101) is running...

  So I'm assuming this means it's running and not hung, is there a better way to
check the status of xfs?  As for the version of Fedora, I've seen folks
reporting here it happens for them on Fedora 7 and 8, both 32 and 64 bit
versions.  That said, I haven't seen this on my laptop or home PC (which also
have 64 bit versions of 7 and 8 respectfully), just on the machines at the
university, where the home directories are being NFSed from a fileserver
(running F7 x86_64, directory is XFS type w/ software RAID 0) and controlling
login vi Fedora Directory Server (ldap).
  Maybe the problem I'm having with Fedora 7 is different than yours with Fedora
8, but they both appear to have started with the same kdebase update back in
November.  So either they are related or a very strange coincidence.  I'm
willing to start another bug post if you think they are not related.  If there's
something in particular I can check for when this conditions happens that would
help the investigation (files, etc.), please let me know.  With 24 machines and
~70 active student users, I'm seeing it a lot in the lab.     

Comment 43 Rex Dieter 2008-02-25 03:06:14 UTC
Re: problem starting in November

The only item in the changelogs remotely relavent is in kdebase:
* Wed Nov 28 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-9
- adapt updated ConsoleKit patch from Mandriva (Nicolas Lécureuil) to fix xdmcp
  issues (bug #243560, Mandriva#34786)

But that patch touches *only* kdm (so shouldn't have any effect on gdm users).

Comment 44 Ray 2008-02-25 03:40:06 UTC

> So I'm assuming this means it's running and not hung

No, it just means there's a kernel process in existence.  If it's stuck in a 
wait state then it won't show any new cpu use, but that in itself doesn't 
necessarily mean it's hung (maybe it really just has nothing to do or maybe 
it's using so little cpu that it doesn't register with top).  If it's stuck in 
an endless loop then you'll see it using a lot of cpu.  In either situaton, the 
process exists (i.e. it's "running") but it won't respond to any client 
programs (which often has the same effect as it not running at all).

As for the F7 vs. F8 business, I upgraded from F6 to F7 and then immdiately to 
F8 and spent virtually no time at all running in F7.  I probably never even ran 
X.  So I can't really comment on any F7 issues.  Maybe they're related, maybe 
not.  We'll probably know eventually but there's no way to say at the moment.


Comment 45 mb 2008-02-25 05:36:26 UTC
I reported earlier that I have 3 new machines, all installed with F8 i386 in the
last two weeks, and all are exhibiting this problem.

One more datapoint, tonight I installed (not upgraded) F8 over a previous F7. 
F7 hadn't been updated since October and was not showing any KDE logout
problems.  But tonight with F8, I'm seeing the same problem on this machine as well.

Intermittently, when a user logs out of KDE ("End Current Session"), the screen
goes dark but the mouse cursor remains, and startkde becomes a zombie child of

I know others here run KDE every day and aren't seeing this, but I seem to be
able to recreate it on multiple machines.

I'll try some VMs as well.  Is there anything I should be doing trace this, or
are any of my log files useful in debugging this?

Is there a workaround?

Comment 46 Rex Dieter 2008-02-25 12:37:38 UTC
Re: workaround?

Most folks experiencing problems seem to be using gdm, so I'd suggest giving kdm
a whirl.  In the meantime, testing if kde-3.5.9 helps any would be helpful:

Comment 47 mb 2008-02-25 14:42:49 UTC
I'll try changing from gdm to kdm.  But from Comment #9, kwhiskerz says that's
no help:

> the bottom line is that neither GDM nor KDM work properly with
> KDE, but work fine with Gnome.

Comment #1 says:

> Switch to using kdm instead of gdm.  
> Edit /etc/sysconfig/desktop to contain:

I don't have a 'desktop' file in the sysconfig directory, is that right? Should
I create it?

I'll try testing kde-3.5.9 but the site is down now.

Comment 48 Rex Dieter 2008-02-25 15:07:50 UTC
> from Comment #9, kwhiskerz says that's no help:

I'd like more feedback.

> I don't have a 'desktop' file in the sysconfig directory, is that right? Should
> I create it?

Yes.  create/edit /etc/sysconfig/desktop to contain (at least):
and reboot.  And/or
rpm -e gdm
either or both will get you a system using kdm. :)

Comment 49 mb 2008-02-25 15:45:31 UTC
(In reply to comment #48)

>> from Comment #9, kwhiskerz says that's no help:
> I'd like more feedback.

Tried KDM instead of GDM on one machine, and the results look good.  Logged in
and out more than 30 times, with multiple users, switching among multiple open
sessions, and could not recreate the zombie startkde issue.

And DISPLAYMANAGER="KDE" does the trick for me.

Two minor issues/questions:

1. I did have one instance where logging out resulted in a blank screen.  But
this time there was no mouse cursor, only a blinking underscore in the top left
corner.  It happened when I had multiple sessions open, so maybe logging out of
one session dropped me back into a closed session.  There was no zombie startkde
process, so this is probably a different issue.  If I can recreate it I'll
search for an existing issue or create a new one.

2. I can no longer change the login screen through Administration | Login Window
because that uses gdmsetup and gdm isn't running.  Is there an equivalent

I'll run with this for a day, then replicate to the other machines if it holds up.

Thanks for the workaround!

Comment 50 Kevin Kofler 2008-02-25 21:46:15 UTC
KDM is configured through kcontrol (in KDE 3; in KDE 4, it will be 

Comment 51 mb 2008-03-01 06:26:50 UTC
I've now been using KDM instead of GDM on three machines for five days, and
everything works fine.

So it appears the issue is with GDM?

Comment 52 Ian Donaldson 2008-03-04 07:15:56 UTC
On FC7 i386 and selinux with enforcing/targeted mode with NFS homedirs, 
with updates to Oct 2007 approx, kde logout was no problem here 
(on about 30 identical desktops), although there were reports that the 
logout-shutdown options often had the black screen with cursor issue.

Upon yum-updating a few desktops to Feb 19 level nearly all updated machines 
suddenly had problems with plain kde logout itself hanging with the 
black screen + cursor.

No selinux reported messages; xfs not dying either.

I've just done another yum update on one PC to bring it up to today (Mar 4),
rebooted and the problem seems to have vanished; although it was 
100% repeatable prior to the update, and in this case the OS was freshly 
kickstarted last night with upto Feb 19 updates applied (from a local 
install/update cache).

The updates today were only these:

 cups                    i386       1:1.2.12-9.fc7   updates           3.0 M
 cups-libs               i386       1:1.2.12-9.fc7   updates           187 k
 dbus                    i386       1.0.2-7.fc7      updates           462 k
 dbus-x11                i386       1.0.2-7.fc7      updates            31 k
 kde-filesystem          noarch     4-8.fc7          updates            17 k
 libnetfilter_conntrack  i386       0.0.82-1.fc7     updates            44 k
 libsilc                 i386       1.0.2-5.fc7      updates           412 k
 libtunepimp             i386       0.5.3-11.fc7     updates           386 k
 logwatch                noarch     7.3.4-11.fc7     updates           295 k
 mikmod                  i386       3.2.2-6.fc7      updates           230 k
 perl                    i386       4:5.8.8-28.fc7   updates            10 M
 perl-CPAN               i386       1.76_02-28.fc7   updates           127 k
 perl-ExtUtils-Embed     i386       1.26-28.fc7      updates            34 k
 perl-ExtUtils-MakeMaker  i386       6.30-28.fc7      updates           288 k
 perl-Test-Harness       i386       2.56-28.fc7      updates            78 k
 perl-Test-Simple        i386       0.62-28.fc7      updates           109 k
 perl-devel              i386       4:5.8.8-28.fc7   updates           384 k
 perl-libs               i386       4:5.8.8-28.fc7   updates           567 k
 perl-suidperl           i386       4:5.8.8-28.fc7   updates            59 k
 pinentry                i386       0.7.4-1.fc7      updates            62 k
 pinentry-qt             i386       0.7.4-1.fc7      updates            62 k
 qt                      i386       1:3.3.8b-1.fc7   updates           3.6 M
 thunderbird             i386   updates            24 M

so I'm guessing dbus or kde-filesystem changes could have been 
related to the fix, although looking at the source changelog I can't see 
anything obvious.

Prior versions of these packages were


Comment 53 Rex Dieter 2008-03-04 15:39:56 UTC
I (still) can't reproduce here using gdm (tried ~10 various logins).

Re: comment #52 updates
I don't see any changes there that seem relevant to this issue, but who knows.

Comment 54 jmccann 2008-03-04 16:10:58 UTC
Try turning debugging mode on in gdm.  In /etc/gdm/custom.conf put a
"Enable=true" line under the "[debug]" section.

Then check syslog for messages when you reproduce the problem.

You can also attach gdb to the various gdm processes and try to trace what is
going on.

It would also be useful to know if this problem occurs in Rawhide.

Comment 55 Ian Donaldson 2008-03-05 01:07:26 UTC
Cancel that; same updates applied to another identical PC don't solve this.

Comment 56 Ian Donaldson 2008-03-05 03:43:27 UTC
Created attachment 296840 [details]
gdm syslog + gdb + strace output

Attached are gdm syslog, gdb + strace outputs.

I've included the syslogs from machine 'cs05' where the logout hung,
and 'cs02' where it succeeded.	Identical hardware, OS and patch level.

strace shows gdm hung in a futex() on cs05.  The X server hasn't exited
yet, so I'd say that gdm hasn't yet woken up to kill the X server.

Comment 57 mb 2008-03-08 20:09:54 UTC
I had 4 machines with this problem, and on Feb 25 the KDM workaround fixed the
problem for all the machines.  (Created a file called 'desktop' in
/etc/sysconfig with one line DISPLAYMANAGER="KDE"

But I yum updated one of the machines last night, and now the machine fails to
log out *every time*.  Before, the screen would go blank and the mouse cursor
would remain.  Now, the screen goes blank with no mouse cursor.

I removed the workaround 'desktop' file from /etc/sysconfig (back to gdm instead
of kdm), and now it's back to it's old behavior.  I can logout successfully
about 4 times out of 5.  1 time in 5 I get the blank screen with mouse cursor,
and a zombie startkde process.

Any idea why kdm is failing every time now?  What info or logfiles can I provide?

Here's what yum updated last night.  It was working fine before this update.

Mar 07 18:45:55 Installed: gmime - 2.2.10-5.fc8.i386
Mar 07 18:45:55 Installed: gmime-sharp - 2.2.10-5.fc8.i386
Mar 07 18:46:03 Installed: tomboy - 0.8.2-1.fc8.i386
Mar 07 22:49:07 Updated: setroubleshoot-plugins - 2.0.4-4.fc8.noarch
Mar 07 22:49:08 Updated: python-exif - 1.0.7-4.fc8.noarch
Mar 07 22:49:18 Installed: kernel-devel -
Mar 07 22:49:19 Updated: kernel-headers -
Mar 07 22:49:20 Updated: tzdata-java - 2007k-2.fc8.noarch
Mar 07 22:49:21 Updated: tzdata - 2007k-2.fc8.noarch
Mar 07 22:49:22 Updated: krb5-libs - 1.6.2-13.fc8.i386
Mar 07 22:49:22 Updated: audit-libs - 1.6.8-2.fc8.i386
Mar 07 22:49:29 Updated: kdelibs - 6:3.5.9-4.fc8.i386
Mar 07 22:49:29 Updated: taglib - 1.5-1.fc8.i386
Mar 07 22:49:33 Updated: amarok - 1.4.8-4.fc8.i386
Mar 07 22:49:47 Updated: evolution - 2.12.3-3.fc8.i386
Mar 07 22:49:49 Updated: libtirpc - 0.1.7-15.fc8.i386
Mar 07 22:49:50 Updated: audit - 1.6.8-2.fc8.i386
Mar 07 22:49:50 Installed: amarok-konqueror - 1.4.8-4.fc8.i386
Mar 07 22:49:53 Updated: evolution-help - 2.12.3-3.fc8.i386
Mar 07 22:49:54 Updated: audit-libs-python - 1.6.8-2.fc8.i386
Mar 07 22:49:54 Updated: krb5-workstation - 1.6.2-13.fc8.i386
Mar 07 22:50:44 Installed: kernel -
Mar 07 22:50:44 Updated: synaptics - 0.14.6-2.fc8.i386

Comment 58 mb 2008-03-08 20:11:42 UTC
Also (sorry for the newbie question), can I undo last night's yum update and
revert to the previous state?  It was working beautifully with kdm.

Comment 59 Kevin Kofler 2008-03-08 20:31:02 UTC
Uh... The *only* change in that kdelibs update is:
* Tue Mar 04 2008 Kevin Kofler <Kevin.org> - 3.5.9-4
- hardcode qt_ver again because 3.3.8b reports itself as 3.3.8 (fixes apidocs)
and I don't see what other update could have caused this.

It's also quite possible that the issues with KDM are a separate bug, so I'm 
not sure this is the right place to discuss them.

Comment 60 Ray 2008-03-08 21:04:55 UTC
> It's also quite possible that the issues with KDM are a separate bug, so I'm 
not sure this is the right place to discuss them.

Umm, separate from what?  It is a bug in a Fedora distribution so this location 
certainly seems appropriate to me.  And he's running F8 which is what this bug 
report relates to (and *not* F7, as I've pointed out before...)

mb: Did you check xfs?  Your symptoms sound similar to mine and the xfs problem 
is 100% consistent (and persistent) for me.  Do you know if there were any xfs 
or xorg updates in your recent update?

BTW, I stopped looking into this bug because I found out that my laptop (which 
belongs to my employer) is scheduled to be retired (against my will) in a few 
weeks.  My replacement will have winblows on it initially but I plan to replace 
that with F9 when it comes out (I need the new disk encryption stuff).  If 
anyone finds a fix or workaround though in the meantime I'll be happy to test 


Comment 61 Kevin Kofler 2008-03-08 21:08:49 UTC
Separate from the bug this bug report is about. Separate issues should be 
reported in separate bug reports because otherwise it's hard to keep track of 
what's fixed and what not.

Comment 62 Ray 2008-03-08 21:24:50 UTC
Okay, but it's not clear to me that kdm vs gdm is a separate issue.  The main 
symptom that everyone shares is kde hanging on logout.  Until more concrete 
evidence appears about the cause it's not unreasonable to assume a relationship 
and it's probably useful to keep the information for both in one place (at 
least until it becomes clear there is a separate issue).  (F7 bug reports, 
OTOH, probably are a separate issue...)

Comment 63 Kevin Kofler 2008-03-08 21:27:13 UTC
I'm not sure about that last part. The KDE we're shipping in F7 and F8 is 
almost the same, the specfiles are in sync and there are very few conditionals. 
So there too, we don't know if the issues are related or not without more 

Comment 64 Ray 2008-03-08 21:48:14 UTC
Well, maybe not then; but the symptoms do sound different; and "almost" and 
"very few conditionals" are not all that reassuring...

Comment 65 mb 2008-03-09 18:34:14 UTC
There are a number of reports of kde logout issues with blank screen + mouse
cursor in last 6-8 weeks on other forums.

Here's one:

> Someone told me to try adding echoes in my /usr/sbin/startkde script
> ...
> It looks like the hang happens with kwrapper ksmserver section. 

Comment 66 mb 2008-03-09 19:00:04 UTC
This debian user was able to work around the logout problem by killing acpid
prior to logging out:


> killed only the process:
> /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket
> ...
> Ended session and was able to get back to GDM.

Comment 67 Ray 2008-04-05 18:24:14 UTC
I have an update on this from my end (i.e. xfs dying):

I just retired the old laptop that I was experiencing these problems on.  I now 
have a new laptop with a fresh install of F8 (and fully encrypted disk).  I've 
noticed two interesting things:

1) I have no logout problem any more.  It works perfectly every time.  This 
suggests that the issue may be related to updating over old versions (my old 
laptop had been updated through every version since RH9).

2) There is no sign of xfs even being installed on this system!  It just 
doesn't exist.  The xorg-x11-xfs package does not exist and no other xorg 
package seems to include xfs.

So, if anyone else is experiencing issues with xfs, as I was, the solution may 
be to just uninstall xfs.  Apparently it's obsolete.  I haven't tested that 
however, so I'm not guaranteeing anything.  If you try it, be sure to keep a 
copy of the package handy so you can restore it if your system breaks.

Good luck to everyone else with these issues...


Comment 68 Joseph O Morrow 2008-04-11 23:42:11 UTC
I have Fedora 7 on my dual core pentium machine. Ever since I switched my
account to KDE, have had the hanging logout with movable mouse cursor. My son
switch to KDE soon after, and to my knowledge he logs out of KDE fine 100% of
the time. He mostly plays local and internet games, while I practice some
software development (C, C++, Python, Perl). Does this make a difference for

Comment 69 Joseph O Morrow 2008-04-11 23:45:51 UTC
More details concerning above: My son and I have different accounts on same
machine. Wife and daughter use Gnome, and therefore logout fine.

Comment 70 David Benjamin 2008-04-17 17:59:10 UTC
I am running Fedora 8, clean install (not an upgrade), GDM, and this occurs
often for me when logging out of KDE.

I added logger statements to the startkde script at various points, and the logs
appear to show that, even when hanging, the entire script succeeds in running.

Comment 71 Rex Dieter 2008-04-17 18:11:50 UTC
If more folks could provide the gdm debugging information as requested in
comment #54 , that would help a bunch.

Comment 72 Kevin Kofler 2008-04-17 18:15:24 UTC
What I'd also like to know is if this still happens with the rewritten GDM in 
F9 or if it is a F7/F8 only issue.

Comment 73 Rex Dieter 2008-04-17 18:21:27 UTC
Kevin (comment #72), no reports on f9/kde4 so far (*crosses fingers*).

Comment 74 David Benjamin 2008-04-20 22:18:54 UTC
Created attachment 303077 [details]
/var/log/messages with gdm debug info

Here's the relevant bit of /var/log/messages from when it happens on my
machine. The logger/startkde lines at the bottom are from lines I inserted into
the startkde script.

Specifically, they are placed after the echo lines (I couldn't find a way to
access the stderr, so I had the output duplicated), as well as a "Done with
scripts" line right after the last for loop.

I forgot to attach gdb before restarting the login manager. I will try to
remember to do it the next time it happens.

Comment 75 Rex Dieter 2008-04-30 17:46:19 UTC
Related to X server bug #443320 , folks using kdm can try the quick-n-dirty
workaround of adding to /etc/kde/kdm/kdmrc:
which may or may not help here.

Comment 76 Markku Kolkka 2008-05-20 13:38:06 UTC
Created attachment 306119 [details]
Section of log file when KDE logout fails

F8 x86_64, gdm-2.20.5-1.fc8, kdebase-3.5.9-7.fc8
Hardware configuration:

Logfile section starting from when logout command was given from KDE.

Comment 77 Rex Dieter 2008-05-20 13:53:09 UTC
CC'ing Jon, since he's the one who asked for the log.

Comment 78 Rex Dieter 2008-09-06 18:12:15 UTC
jmccann, ping, any chance to look at the logs here that you asked for?

Comment 79 jmccann 2008-09-07 13:24:10 UTC
Does this occur with gdm from F9 or rawhide?  If not then please report this bug to GDM 2.20 upstream.  Thanks.

Comment 80 Peter Gückel 2008-10-24 17:55:39 UTC
Presently, in F10, this has not been an issue. A new bug can be filed, should the problem recur. There is no point in keeping this open for an antiquated Fedora version I no longer use (since 2007).

Comment 81 Kevin Kofler 2008-10-25 01:04:48 UTC
F8 is still supported.

Comment 82 Bug Zapper 2008-11-26 09:32:45 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 83 Bug Zapper 2009-01-09 07:37:15 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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