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 recurs. Version-Release number of selected component (if applicable): kdebase-3.5.8-30.fc8 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.
Can you try an experiment? Switch to using kdm instead of gdm. Edit /etc/sysconfig/desktop to contain: DISPLAYMANAGER=KDE And restart. Does the problem remain?
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: It's DISPLAYMANAGER="KDM", not "KDE"! 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 GDM. 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).
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.
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.
OK, I will switch it back to KDE and see what happens. Back in about 5.
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 should. 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: init-+-/usr/bin/sealer |-acpid |-apcupsd---{apcupsd} |-atd |-auditd-+-audispd---{audispd} | `-{auditd} |-console-kit-dae---61*[{console-kit-dae}] |-crond |-cupsd |-2*[dbus-daemon---{dbus-daemon}] |-dbus-launch |-denyhosts.py |-gdm-binary---gdm-binary-+-X | `-startkde So it is not just my setup.
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.
[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.
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). ~ray
(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 bearing.
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?
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). ~ray
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.
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.
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.
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).
I have updates-testing enabled. The most recent packages (installed) I have received are: > rpm -q kdelibs kdebase kdelibs-3.5.8-19.fc8 kdebase-3.5.8-30.fc8 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 problem).
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.
(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?
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? ~ray
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 desktop. Now to find out why xfs is dying... ~ray
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.
Confirmed. 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.
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.
xfs is dieing (reassigning, for real this time).
I dug this out of my logs: ---- /var/log/messages: Jan 27 14:31:17 lapdog kdm[2180]: X server for display :0 terminated unexpectedly Jan 27 14:31:17 lapdog kdm[2180]: Unable to fire up local display :0; disabling. ---- /var/log/kdm.log: 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. ~ray
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. ~ray
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 PlaylistWindow/PlaylistWindow QObject::connect: Incompatible sender/receiver arguments StarManager::ratingsColorsChanged() --> ContextBrowser::ratingOrScoreOrLabelsChanged(const QString&) STARTUP 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).
Maybe your /etc/X11/fs/config (the xfs config file) is corrupt?
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, /usr/share/X11/fonts/75dpi:unscaled, /usr/share/X11/fonts/100dpi:unscaled, /usr/share/X11/fonts/Type1, /usr/share/X11/fonts/TTF, /usr/share/fonts/default/Type1, # 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.
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 +kcminit_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 /tmp/ksocket-mb/klauncherzD1QZ 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 PID TTY STAT TIME COMMAND 20826 ? S 0:00 /usr/sbin/gdm-binary -nodaemon Seems like a serious problem, shouldn't it be a higher priority than 'low'?
Re: comment #31 Tim, in this context xfs = X Font Server
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.
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?
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.
(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.
Please keep this at 1 issue per bug report! Your 1. is probably Bug 434624, please add any additional information you have there. 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.
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 ~ray
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?
> OK, that may work for those who are experiencing this problem caused by xfs dieing, 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. ~ray
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.
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).
Tim, > 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. ~ray
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 gdm-binary. 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?
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: https://admin.fedoraproject.org/updates/F7/FEDORA-2008-1892 https://admin.fedoraproject.org/updates/F8/FEDORA-2008-1889
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: > DISPLAYMANAGER=KDE 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.
> 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): DISPLAYMANAGER="KDE" and reboot. And/or rpm -e gdm either or both will get you a system using kdm. :)
(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 "kdmsetup"? I'll run with this for a day, then replicate to the other machines if it holds up. Thanks for the workaround!
KDM is configured through kcontrol (in KDE 3; in KDE 4, it will be systemsettings).
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?
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 2.0.0.12-1.fc7 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 kde-filesystem-4-6.fc7 dbus-1.0.2-6.fc7 dbus-x11-1.0.2-6.fc7
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.
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.
Cancel that; same updates applied to another identical PC don't solve this.
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.
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 - 2.6.24.3-12.fc8.i686 Mar 07 22:49:19 Updated: kernel-headers - 2.6.24.3-12.fc8.i386 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 - 2.6.24.3-12.fc8.i686 Mar 07 22:50:44 Updated: synaptics - 0.14.6-2.fc8.i386
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.
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.
> 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 it. ~ray
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.
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...)
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 evidence.
Well, maybe not then; but the symptoms do sound different; and "almost" and "very few conditionals" are not all that reassuring...
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: http://www.kde-forum.org/artikel/17919/Starting-up-KDE-hangs-with-a-black-desktop-and-mov.html > Someone told me to try adding echoes in my /usr/sbin/startkde script > ... > It looks like the hang happens with kwrapper ksmserver section.
This debian user was able to work around the logout problem by killing acpid prior to logging out: http://www.mail-archive.com/debian-qt-kde@lists.debian.org/msg20419.html > 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.
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... ~ray
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 anybody?
More details concerning above: My son and I have different accounts on same machine. Wife and daughter use Gnome, and therefore logout fine.
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.
If more folks could provide the gdm debugging information as requested in comment #54 , that would help a bunch.
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.
Kevin (comment #72), no reports on f9/kde4 so far (*crosses fingers*).
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.
Related to X server bug #443320 , folks using kdm can try the quick-n-dirty workaround of adding to /etc/kde/kdm/kdmrc: TerminateServer=true which may or may not help here.
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: http://www.smolts.org/client/show/pub_b6451a8c-fbe5-48d9-a445-cb84f73a46ad Logfile section starting from when logout command was given from KDE.
CC'ing Jon, since he's the one who asked for the log.
jmccann, ping, any chance to look at the logs here that you asked for?
Does this occur with gdm from F9 or rawhide? If not then please report this bug to GDM 2.20 upstream. Thanks.
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).
F8 is still supported.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.