Bug 334321 – gnome-base/gnome-applets: System Monitor (multiload-applet-2) fails to appear or disappears

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description Robert Bradbury 2010-08-24 17:26:43 UTC]

Running a normal gnome session which involves previously working Multiload applet monitor: /usr/libexec/multiload-applet-2 now fails.  The applet either appears (e.g. at login) then disappears or fails to appear when added to a panel.




Reproducible: Always

Steps to Reproduce:
1. Login to gnome
2. Select a panel, right-click, select "Add-to-panel", select "System Monitor - A System Load Indicator", click [Add], click [Close]
3. No system monitor appears.

Actual Results:  
The applet is running:
F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN    RSS PSR STIME TTY          TIME CMD
0 D firefox   2247     1  0  80   0 -  5980 rpc_wa  9308   0 09:36 ?        00:00:00 /usr/libexec/multiload-applet-2 --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=30
0 D firefox  15076     1  0  80   0 -  5980 rpc_wa  9304   0 07:44 ?        00:00:00 /usr/libexec/multiload-applet-2 --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=30
0 D bradbury 30386     1  0  80   0 -  6008 rpc_wa  4816   0 Aug23 ?        00:00:00 /usr/libexec/multiload-applet-2 --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=42


Expected Results:  
Preconfigured monitors should run on login.
Newly added monitors should show up on panel selected.

Monitors that happen to run on login "lose" their connection to the panel.
New monitors don't appear on any panel.

Interestingly they show up in a "D" state with a wchan of "rpc_wait_bit_killable".

This all used to work before a couple of system changes:
a) Upgrade to glibc-2.12.1-r1 (which involved compiling several packges as "-static" instead of "static").
b) Upgrade to use system-wide "policykit" as suggested in Bug #331543.

[Comment 1 Robert Bradbury 2010-08-24 17:27:24 UTC]

Created attachment 244425 [details]
emerge --info

[Comment 2 Robert Bradbury 2010-08-24 17:36:24 UTC]

Interestingly if one tries to run gdb on one of the multiload-applet-2 PIDs it hangs.  The processes themselves cannot be killed with either a SIGSEGV or SIGABORT to attempt to generate a core dump and the gdb, once "hung", cannot be killed either.

I believe with "normal" session what should happen is that gnome-panel will notify you that an application has terminated and request confirmation as to whether or not it should be left in the preferences or be deleted.  In this case, no gnome "pop-up" window appears to request this.

[Comment 3 Pacho Ramos 2010-08-26 09:13:14 UTC]

I am unable to reproduce at all, but I am still using glibc-2.11.2 :-/

Could you retry on a new created user account?

[Comment 4 Pacho Ramos 2010-08-31 13:13:31 UTC]

We will also wait for http://bugs.gentoo.org/show_bug.cgi?id=334307#c7

[Comment 5 Robert Bradbury 2010-09-01 12:08:16 UTC]

See Bug #331543, comment #8.  After fixing the messagebus members in /etc/group and rebuilding gnome-panel and gnome-applets -policykit the problem does not seem to occur.

However "gvfs-gdu-volume-monitor" core dumps when logging into root *do* still occur as does the .gnomerc-errors: "GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/libexec/gvfs-gdu-volume-monitor received signal 6".

I strongly suspect this is because there are "dbus" configuration settings which are not "up-to-date" and I don't know of any Gentoo utilities which verify these settings (no /usr/bin/dbus-sanity-check).