Gnome fallback - intermittent menus on top panel

[Matt Johnson]

Ubuntu 12.04.1, up-to-date.

Using gnome fallback session on fat clients via ltsp, sometimes a user is presented with an empty top panel (no Applications menu, no Places menu, no indicators). The panel is there but no menus. This happens perhaps 1 in 20 logins and across various users and various machines. Workaround is a desktop launcher (named FixMyMenu) that the user can run that calls the following script:

#!/bin/sh
killall gnome-panel
gnome-panel

This works in the vast majority of cases, though occasionally needs to be run more than once before the menus appear on the panel.

[Alkis Georgopoulos (alkisg)]

I've been seeing that too, in standalone workstations as well.
It's causing significant problems in classrooms where the teacher doesn't know the commands to restart gnome-panel.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alkis Georgopoulos (alkisg)]

I've just experienced it again in an LTSP fat client. Gnome-panel was showing but without any text, looked liked it hanged while loading.
strace -p $(pidof gnome-panel) displayed only the following:

# strace -p 1928
Process 1928 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>

In .xsession-errors I saw the following but I don't know if they were printed by gnome-panel:
Προειδοποίηση διαχειριστή παραθύρων: Log level 8: meta_display_unregister_x_window: assertion `g_hash_table_lookup (display->window_ids, &xwindow) != NULL' failed
Προειδοποίηση διαχειριστή παραθύρων: Άκυρο WM_TRANSIENT_FOR παράθυρο 0x3a00001 που καθορίστηκε για 0x3a00003 (Ανώνυ).

The first line translates to "window manager warning",
and the second one to "window manager warning: cancelled WM_TRANSIENT_FOR window 0x3a00001 that was defined for 0x3a00003 (No nam...)"

gnome-panel --replace did _not_ work the first time, it resulted in the same non-functioning panel without menus,
but it worked fine the second time I ran it.

I should also note that LTSP fat clients are using SSHFS, just in case someone finds out it's related to file locking or something.
We weren't experiencing it in 10.04 with NFS /home (300 schools, worked fine for 2 years), but that was Gnome 2 though.

[boukeas (boukeas)]

I 've been experiencing the exact same problem with Ubuntu Precise LTSP fat clients and gnome-fallback-session. I am using it in a computer lab and it's quite disruptive, with the empty top panel appearing in at least 1 out of 10 logins. I have also noticed both panels disappearing in the middle of a session but I am not sure it's related.

[Aspasia Dilalou (adilalou)]

I had the same problem 4-5 times in fat clients.

[markakis (grigoris-markakis)]

I have encountered the same problem several times (12.04 LTSP fat clients with gnome-fallback-session)

[Eleni (elefat)]

Same problem here: 1-2 out of 11 fat clients need gnome-panel replace each time a classroom logs in. I have not experienced the same problem in thin clients yet. A couple of times I had to log out, because even killall gnome-panel did not fix the problem.

[Alkis Georgopoulos (alkisg)]

Here's a script that makes gnome-panel try twice to get loaded properly, so it should avoid the need for a desktop launcher that kills the panel for most of the cases; for the few that will remain, a logout/login should suffice...

Greek teachers shouldn't apply it, it'll come as an update from our ts.sch.gr PPA.

Create /opt/ltsp/i386/usr/local/bin/gnome-panel, with the following contents:

#!/bin/sh

if [ "$LTSP_FATCLIENT" != "True" ]; then
    exec /usr/bin/gnome-panel "$@"
fi

/usr/bin/gnome-panel "$@" &
sleep 10
if ! pgrep -nx indicator-sound -U $USER >/dev/null 2>&1; then
    echo "$(date) - restarting gnome-panel" >> $HOME/.xsession-errors
    exec /usr/bin/gnome-panel --replace
fi

And just a bit more debugging info, in case anyone's interested:
* On a client that has the problem, the gnome-panel process is there, but all the applet processes (e.g. indicator-sound-service) aren't.

* The .xsession-errors of a client that doesn't have the problem, contains:
Initializing nautilus-gdu extension
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon
** Message: moving back from GtkStatusIcon to indicator
...while on a client that does have the problem, the last line is missing (i.e. it hangs somewhere between outputing those 2 lines)

* I tried removing everything from /etc/xdg/autostart, except for gnome-settings-daemon.desktop, and the problem did appear to become more rare, but eventually it did happen again on 1 client after rebooting 10 clients 6 times (while usually it happens on 1 out of 10 clients, every time).

[alexxtasi (alexxtasi)]

Also affects me... running ltsp in a school lab with 12 fat-clients.

[David Groos (djgroos)]

Had this exact problem--is disruptive in a classroom for sure. Details on alkisg solution in #8 above:

He says:
...Create /opt/ltsp/i386/usr/local/bin/gnome-panel, with the following contents:...

Another way to say this would be:
1. ...Create /usr/local/bin/gnome-panel, with the following contents:...
2. ...Re-build the image

(then this script just created will be in the image at /opt/ltsp/i386...)

At least this is my understanding! Thanks alkisg and vagrantc!