Michael Crute schreef: > On 9/10/05, *Dave Nebinger* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > A google search turned up another message: > >> I had this too after I botched a VNC install. I solved it by >> purging /tmp and all the config files in my home directory. There >> is probably a better way but it was a new install and I didn't have >> my files on it anyhow. So try creating a new user with a new home >> directory and see if that fixes things. > > Don't know if that applies to you, though. > > > Hmm... feeling some dejavu with that quote. Odd. Anyhow in that one I > wasn't quite talking about this issue. The times I have had this > happen are when I do something to crash Gnome. Typically a sudo > killall gnome-panel from a regular terminal is all it takes to fix > this. > > -Mike > Yes, but that doesn't necessarily fix it permanently, depending on your settings.
Here's the deal (afaik, based on my long experience with GNOME): One of 2 variations of the same situation seem to cause this issue: 1) there is a previously crashed panel (zombie) trying to start when the session is loaded; 2) there is a previously crashed panel applet (zombie) trying to start an instance of the panel when the session is loaded. The overall issue is that the gnome-panel is always set to 'restart' in the session manager (so if it crashes, the panel would automatically attempt to restart, as you don't have much of a GNOME desktop without the panel), and (of course), any panel applet that wants to run is going to attempt to start the panel (because the applet depends on the panel running). The secondary issue is your individual settings for 'save session on exit'. If the last saved session contains this zombie process, it's going to attempt to restart whenever you login, because that's what the purpose of the saved session is (to restore the session as it was when saved, irrespective of its state of cleanliness). So what has to be done is that the saved session itself has to be cleaned of this zombie process. The problem is that much of the time, these zombie processes do not appear in any system monitor (under 'normal' circumstances). Two ways to do this (I find 'the long way' more reliable, but both should theoretically work): 1) Go to GNOME Control Center => Advanced => Sessions and find out what your session save settings are in the first place. The short way: Set the session save to 'ask me on logout' The long way: Turn off all session saving. If you're going the short way, now do a killall -9 gnome-panel in a terminal. This should be sufficient if the problem is a crashed panel, but it won't necessarily be if the problem is a crashed applet. For example, I normally have this problem when I first install GNOME, and the mixer applet-- which is a default applet-- crashes due to not being yet properly set. The mixer applet is default, so it's always going to attempt to start, and when I get the settings fixed, it will start normally, but prior to that I probably got a message that the mixer applet was crashed and do I want to remove it from the panel layout? Well of course I don't, *but* what seems to really happen is that when I correct the settings in the Sound area of the Control Panel or whatever, the 'original' applet doesn't get fixed and start, but a new, fixed instance of the applet starts. So the original crashed applet that I didn't remove is trying to start an instance of the panel, and the new, working instance of the applet is trying to start a panel. The solution to this is usually to remove all instances of the applet (which may require going to gconf-editor to fix the crashed one, since I didn't take the layout out of there when I had the chance), and add the applet back to the panel (so that one instance only is requested), and save the session (so that the session where both applets are attempting to start is overwritten). Yeah, OK, the 'short way' isn't all that short, but GNOME can be fairly obtuse at times. Log out and explicitly save the session, then log back in. If the problem was simply a zombie instance of the panel, it should now not attempt to restart, and the 'regular' panel should start normally (although this has never really worked for me, it's *supposed* to). You can then set your Session settings back to 'automatically save session on exit' or whatever you like. The long way: Log out (you've turned off session saving, so your current settings will not be saved again). Log back in to the 'GNOME failsafe session', which should be listed in your list of sessions if you use GDM. If you use KDM, I'm not sure, and I'm also not sure how you get into it using startx (I'd have to look in my sessions folder, which I'll do after I finish this). The idea of the failsafe session is that it's not going to run any 'startup scripts' (whatever those are for GNOME), but just the essentials of the default session. In any case, whatever it means, the result as I have seen it is that: 1) GNOME will start (possibly with the same error dialogs, but it will actually start, which is useful if the crashed process is preventing the session from starting at all); 2) the zombie processes will be visible in gnome-system-monitor (which is the really useful thing). Kill all the zombie processes, fix your panel, whatever is necessary based on the error dialogs. If you get messages saying that one or more applets are crashed, do you want to remove them from the config, say 'yes' unless you are absolutely sure that it's impossible that there should be more than one instance of the applet running (because you added it yourself, one time, and it's a free-standing applet that doesn't load by default as the mixer and notification area do.). But even then, you might want to remove it because 1) you can always add it back later, when the panel is fixed, and 2) if you're sure that the applet has only one instance running, and that instance is crashing, do you want this applet on your panel anyway? Probably not. Go into GNOME-Control Panel => Advanced => Sessions and choose 'ask me to save session' (automatic should theoretically work as well, but I'm not completely convinced that it does, so I save manually). Log out and save the session (you'd think that this would save to the 'failsafe' session, but it actually saves to the 'default' session, which is what we want). Log back into your regular session and it should be fixed (because the default session is now 'clean'). Again, you can now set your session saving properties to whatever you prefer. Addendum: I see that the command to start gnome-session with the failsafe session is (unsurprisingly) gnome-session --failsafe but I don't see how this is called as a listed session in either GDM, KDM, or even startx (which is normally just calling the 'gnome' script, which starts gnome-session as a part of the entire script). So sorry that I don't feel like digging further at this moment as to how to get this done if you don't use GDM for whatever reason. But I hope this helps, Holly -- gentoo-user@gentoo.org mailing list
