gnome panels are empty (show nothing) after login

Thanks for your bug. Are the panel frozen or does clicking on the menu emplacement works by example? Do you use some special image for the background or a transparent panel? Does it change on mouseover?

 * I'd say they are not frozen since they respond to right-click and their properities and such work fine.
 * Mouseover has no effect.
 * Background is set to: None (use system theme).

Does it depends of the GTK theme you use? Do you use something fancy like xgl or composite?

John: does clicking where you'd expect the menu to be (eg. the top left-hand corner) produce the drop-down menu you'd expect. If so, is that also empty? Additionally, what graphics card/driver do you have?

I am using the default Ubunutu Human theme. Don't believe I'm using xgl or composite, since those require me actively doing something to enable them, right?

Paul, clicking on the panel where the menu should be does not produce the expected menu. Instead the mouse cursor changes to a hand. I see this is the same cursor as when then panel has been corrected and I click and hold on an empty part of the panel. It would be my analysis that the panel does not get populated rather than some rendering problem.

For the record, I have a Matrox Graphics, Inc. MGA G550 AGP (rev 01).

I still suffer with this problem. Does anybody have an idea what might be a simple cure?

I've thought about mv'ing my .gnome* directories aside or the like to determine why new users have no problems, yet I do simply because I upgraded the OS and kept /home throught it all.

Where does gnome-panel persist its data?

I've only held back because I was hoping to squash a bug.

The configuration is stored to gconf. Are you sure you didn't simply remove the menubar applet from your panel and need to had it again?

Positive I did not "simply remove menubar applet". Both the top and bottom panels are empty, void, devoid of all life and 100% non-responsive -- just a gray pair of gray bars, until I right-click desktop to open a gnome-terminal (via nautilus-open-terminal) and exec "killall gnome-panel". It seems that gnome-panel initializes correctly on all but the first time within my gnome session. Of course, the first time is the most important as the 2nd ... nth times should never be needed. Make sense?

I just made a significant discovery on this bug. If I add a new panel and populate it, this new panel works correctly! The old panels still fail as reported and can still be revived via the killall.

Now I have a predicament. I assume that I can make this problem go away for me by just making new panels to completely mimic my old ones and destroying the old ones. Will that harm the proper resolution of this bug? I can hold for a while if needed -- I've been living with this for several months now, but it sure would be nice to say bye bye bug.

This looks like it might be racey. Doing:

  killall gnome-panel

*sometimes* brings back the panel (rather than displaying it, but the panel not responding). However doing:

  strace -p `pidof gnome-panel`

immediately after killing the previous panel, allows the panel to start successfully; possibly the ptrace was slowing it down sufficiently.

What is gnome-panel racing against?

For the record, doing:

  killall gnome-panel

*always* brings back gnome-panel for me. I've done this 100's of times. :-(

I have permanently resolved this issue (for myself) by creating new replacment panels and dragging all old launchers to the new panels and removing the old (and now empty) panels.

I can now logout and back in and everything works as expected.

Thanks for following up. Unfortunately it's not easy now to find out what caused the problem. If it should re-occur, please re-open the bug. Thanks a lot.

dholbach: is this likely the same bug as all the "gnome-panel hangs on startup" bugs? The solution (killall gnome-panel) seems the same---the bug is still here and occuring about 1 time in 2 for me;

Rejected is perhaps the not the best tag, the issue still exists.

Paul: if you can follow up with a link this is a duplicate of or more information, then it'd make sense to re-open it.

Reopening this. The problem is still here, even if we don't know how to debug it yet.

It could be one of the gnome-applets (wish I think are loaded by gnome-panel) causing input to hang.

I'd be interested to know if it still happens when making /apps/panel/general/applet_id_list (in gconf) an empty list (make sure to save the previous value). (you'll then only see menus and launchers)

Also, does it also mean you can't add anything to the panel?

Any news on Vincent's questions?

Unfortunately, I can no longer provide feedback on this bug. As mentioned on 2006-08-16, I permanently made the problem go away as the problem was getting too annoying, especially when I had solution waiting in the wings (see 2006-08-10).

marking as closed for now then, feel free to reopen if you get the issue again and can replies to the asked questions about it