GNOME Bugzilla – Bug 333032
g-p-m crashes when invoked through a nx desktop session
Last modified: 2006-11-15 09:01:31 UTC
Distribution: Fedora Core release 4 (Rawhide) Package: gnome-power-manager Severity: Normal Version: GNOME2.13.91 unspecified Gnome-Distributor: Red Hat, Inc Synopsis: g-p-m crashes if multiple instances running Bugzilla-Product: gnome-power-manager Bugzilla-Component: gnome-power-manager Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.13.3) Description: Description of the crash: If I'm logged into my desktop machine, and I then try to open a second session to the machine via NX, I get the following crash. Debugging Information: Backtrace was generated from '/usr/bin/gnome-power-manager' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) `shared object read from target memory' has disappeared; keeping its symbols. (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208138064 (LWP 2338)] 0x00980402 in __kernel_vsyscall ()
+ Trace 66612
Thread 1 (Thread -1208138064 (LWP 2338))
------- Bug created by bug-buddy at 2006-03-01 19:34 -------
The session should probably start a new instance of the session dbus server. I would say this is a NX bug. Do multiple versions of NetworkManager also not work?
I have reported this for two or three applets in the past, and it has always been an applet bug, which has been subsequently fixed. However I don't know that the problem was dbus related in the past. I do seem to remember seeing a bug report for NX that said something like that it started a new X server for each session, rather than re-using the current X server. The dbus problem here may be related possibly? I can test NetworkManager tomorrow if you want. I did notice though that Evolution didn't start up when it was running on the local desktop, although I don't know if that is for the same (dbus) reason.
>it has always been an applet bug, which has been subsequently fixed. Got any bugzilla numbers that I can use as reference? Thanks. >I did notice though that Evolution didn't start up when it was running on the >local desktop, although I don't know if that is for the same (dbus) reason. Smells like it's using the same dbus session server, and multiple connections are not being allowed. Richard.
I don't know how relevant these all are. I thought there were more to do with applets. I've certainly seen problems with applets more than I appear to have reported them, although I know for sure there was one bug I reported about an applet once (I just couldn't find it). The following are all pretty much to do with Evolution and dbus problems running on remote displays: http://bugzilla.gnome.org/show_bug.cgi?id=205929 http://bugzilla.gnome.org/show_bug.cgi?id=221098 http://bugzilla.gnome.org/show_bug.cgi?id=263699 http://bugzilla.gnome.org/show_bug.cgi?id=307639
Can you try todays CVS for me please, and tell me what happens.
Umm, I'm not really set up to easily compile from CVS on this machine. When is this likely to hit rawhide, and what is the probable version number I should watch for?
Well, there's no fix, but instead of crashing on load, there is now a nice gtk error message explaining exactly what is wrong.
Please try 2.13.93 (available from http://ftp.gnome.org/pub/GNOME/sources/gnome-power-manager/2.13/) and tell me if this fixes the problem. Many thanks.
With 2.13.93 I get: Warning Power Manager This program cannot start until you start the dbus session service. This is usually started automatically in X or gnome startup when you start a new session. You can launch the session dbus-daemon manually with this command: eval `dbus-launch --auto-syntax` ------- Running the command above and then gnome-power-manager does not cause a second instance of g-p-m to run. However I guess this is better than crashing. What is the fundamental issue with reusing the copy of dbus that is already running? Or with starting a second copy? Nothing else on the desktop seems to have problems. I don't run NetworkManager over the remote connection though because I have had it mess up my network connection far too many times, and can't afford to be cut off when I'm on the remote machine.
>Running the command above and then gnome-power-manager does not cause a second instance of g-p-m to run. Not in the output of ps -A? >What is the fundamental issue with reusing the copy of dbus that is already running? Because it's impossible, as you can only have one dbus named server on the session bus at any one time. >Or with starting a second copy? It would be unable the register it's connection on the bus, and hence useless. I think NX is at fault here. It should start a fresh new session (and hence start a new dbus session server) so that dbus applications just work. I'm no expert on NX, so this might be incorrect. How is g-p-m being launched from the new connection? local/remote gnome-session? Could you not just disable it there? You might be best asking this in a NX forum or mailing list.
OK, so it does start a second instance, but it doesn't put an icon in the system tray: [luke@desertcrossing ~]$ ps aux | grep power luke 2210 0.0 0.4 21672 4328 ? Ss Mar09 0:03 gnome-power-manager luke 17140 0.0 0.0 3916 704 pts/4 S+ 13:45 0:00 grep power [luke@desertcrossing ~]$ eval `dbus-launch --auto-syntax` [luke@desertcrossing ~]$ ps aux | grep power luke 2210 0.0 0.4 21672 4328 ? Ss Mar09 0:03 gnome-power-manager luke 17155 0.0 0.0 3916 676 pts/4 R+ 13:46 0:00 grep power [luke@desertcrossing ~]$ gnome-power-manager [luke@desertcrossing ~]$ ps aux | grep power luke 2210 0.0 0.4 21672 4328 ? Ss Mar09 0:03 gnome-power-manager luke 17158 0.6 0.5 21756 5564 ? Ss 13:46 0:00 gnome-power-manager luke 17160 0.0 0.0 3916 704 pts/4 S+ 13:46 0:00 grep power
I got the following from the NX list. I may not have a chance to run the tests he suggests in the immediate future: From: Kurt Pfeifle <k1pfeifle@gmx.net> Reply-To: kpfeifle@danka.de, User Support for FreeNX Server and kNX Client <freenx-knx@kde.org> To: freenx-knx@kde.org Subject: Re: [FreeNX-kNX] Problem with NX and dbus Date: Tue, 14 Mar 2006 20:35:16 +0000 (15:35 EST) On Tuesday 14 March 2006 18:55, Luke Hutchison wrote: > There seems to be a problem with NX, gnome-session, and dbus, as shown > in the following bug report: > > http://bugzilla.gnome.org/show_bug.cgi?id=333032 > > It appears related to how NX starts new sessions. NX just executes "gnome-session". Unless you've tweaked your "gnome-session" binary (replaced it with a wrapper script?) somehow, Gnome should not see any difference to any other X or remote X session. Did you run the remote NX session as the same or as a different user than the local X session. > Is this really NX's fault, I do not think so. (But that's of course not authoritative.) :) To narrow it down: * run a local X session on your Gnome box * run one or two additional remote X (*not* NX) session on the same Gnome box (* alternatively, run one or more additional local X sessions using Xnest...) * start your additional sessions via "gnome-session" What does happen now? Do you get the same crashes? > or gnome-power-manager, or dbus, or > gnome-session, or what? It would be not the first time that Gnome applets do have problems with when different instances of them run in different (N)X sessions. It was never a problem with NX up to now... > Thanks, > Luke H. Cheers, Kurt ________
What does: ps aux |grep dbus print?
From the local (server) terminal: dbus 1629 0.0 0.0 3196 936 ? Ss Apr27 0:02 dbus-daemon --system luke 1085 0.0 0.0 4096 672 ? Ss Apr28 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session luke 1088 0.0 0.0 2896 516 ? S Apr28 0:00 /usr/bin/dbus-launch --exit-with-session gnome-session luke 1089 0.0 0.1 3068 1216 ? Ss Apr28 0:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session luke 1127 0.0 0.3 14640 3552 ? Ss Apr28 0:00 bluez-pin --dbus luke 21083 0.0 0.0 3920 696 pts/2 S+ 23:57 0:00 grep dbus Do you need to see this from the remote (client) terminal too? Sorry, haven't had time to run through the steps in Comment 12 yet.
Running psaux | grep dbus from the remote login session: dbus 1629 0.0 0.0 3196 956 ? Ss Apr27 0:03 dbus-daemon --system luke 1085 0.0 0.0 4096 524 ? Ss Apr28 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session luke 1088 0.0 0.0 2896 476 ? S Apr28 0:00 /usr/bin/dbus-launch --exit-with-session gnome-session luke 1089 0.0 0.1 3068 1176 ? Ss Apr28 0:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session luke 1127 0.0 0.3 14640 3528 ? Ss Apr28 0:00 bluez-pin --dbus luke 13715 0.0 0.3 14744 3552 ? Ss 13:14 0:00 bluez-pin --dbus luke 14027 0.0 0.0 3920 696 pts/4 R+ 13:26 0:00 grep dbus
Hmm. Those both look okay. Maybe it's a permissions thing for dbus? Does the debug output of g-p-m give any clues when it fails to load in the nx session?
Got any guides for setting up NX for FC5, and I'll try to debug this on my machine?
This worked for me: http://fedoranews.org/contributors/rick_stout/freenx/
Still happen with current CVS?
Does this help: http://permalink.gmane.org/gmane.comp.gnome.desktop/30289
Um, I don't see a solution there, only a description of the problem. However a followup message points to an earlier thread that shows that at least Havoc and Federico are aware of the problem: http://mail.gnome.org/archives/desktop-devel-list/2006-March/msg00102.html
So this is actually a DBUS bug, right?
Not sure if it's a bug in DBUS or gsd or how DBUS is being used... I am not using an NX setup at the moment, so I am not actively running into this anymore.
Okay, talking to the DBUS guys this is likely a DBUS bug, or as you suggest, the way DBUS is being used. I think you should open a new dbus bug or an nx bug if you sttill need this fixed. Thanks.