Recent Gnome upgrades appear to have developed a set of problems coordinating applications. .gnomerc-errors accumulates errors regarding the ownership of 'org.freedesktop.ConsoleKit'. Random errors crop up in other applications, such as the previous report regarding metacity & gnome-panel losing workspace names. This morning it was a GVFS / Volume control / DBus error. I have reason this is a fundamental bug involving Gnome resource controls (ORbit/DBus??), locking but don't understand Gnome well enough to know what it is. Reproducible: Sometimes Steps to Reproduce: 1. Startup a gnome session (2.26...) with many panel applets. 2. Random errors accumulate in .gnomerc-errors of the form: "gnome-session[32398]: WARNING: Could not connect to ConsoleKit: Could not get owner of name 'org.freedesktop.ConsoleKit': no such name" where 32398 is the gnome-session process PID. 3. Attempting to use Alsaplayer and adjust the volume produces an error: "(alsaplayer:4049): GVFS-RemoteVolumeMonitor-WARNING **: cannot connect to the session bus: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken". I've seen such smorgasbord errors before with different applications where the library function involved clearly doesn't seem to know what the problem is. Actual Results: Applications fail in various random ways and generate error messages that give no clue as to how to resolve the problem. Expected Results: A "standard" reasonably complex Gnome session should run without producing errors. gnome-session-2.26.2 gnome-panel-2.26.3 metacity-2.26.0-r1 nautilus-2.26.3 gnome-terminal-2.26.3.1 alsaplayer-0.9.80-r1
Created attachment 200156 [details] emerge --info for system when problems are occuring
how do you start gnome ?
Gentoo is booted through from grub into initstate 3 which is for console use. I then telinit 5 to bring up a more multi-user state which includes X windows. X is managed via xdm (/etc/X11/xdm/Xservers) with the standard X login screen. Logging in defaults to a gnome-session WM. I had originally wanted to get to the point where I ran different WM (gnome, kde, xfce4, etc.) on different VTs for comparison purposes (but have never managed to get to get there). It may be worth noting that these problems seem to be relatively recent, perhaps coincident with upgrading to the gnome 2.26 versions.
(In reply to comment #3) > Gentoo is booted through from grub into initstate 3 which is for console use. > I then telinit 5 to bring up a more multi-user state which includes X windows. > X is managed via xdm (/etc/X11/xdm/Xservers) with the standard X login screen. you mean xdm, gdm, kdm, ... ? also could you list the services in your various runlevels ? 3 and 5 seems to be of interest.
Created attachment 200235 [details] Output of ps --forest showing typical gnome-session Shows a typical gnome-session. Of note may be the fact gimp also seems to be having some kind of a problem. The command "gimp Throbber-small.gif" (See Bug #280369) produces the following error (from gimp): "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." I have not, to the best of my knowledge, changed any of the "as distributed" policies regarding DBus, hal, etc. (I don't even really know what they do). The only unusual thing in my configuration is a command in my .profile "xhost +local:root +local:firefox" which is to allow connections to my "bradbury" owned X display/gnome-session if I am su'ed to root|firefox. This comes up for example if I am trying to run etherape from my non-su login or trying to test firefox (compiled from the CVS distribution as the "firefox" user but being tested on the "bradbury" display).
Once upon a time (a year or more ago?) I used gdm, but went to xdm in the hope of eventually running multiple WM (for which starting from gdm seemed like a bad starting point). Output of "ps -eaf | grep xdm" (after deleting the grep entry): root 7954 1 0 Jul28 ? 00:00:00 /usr/bin/xdm root 8097 7954 1 Jul28 tty8 02:05:13 /usr/bin/X -nolisten tcp -br :0 vt8 -auth /etc/X11/xdm/authdir/authfiles/A:0-DshWT0 root 30740 7954 0 Jul29 tty10 00:14:19 /usr/bin/X -nolisten tcp -br :2 vt10 -auth /etc/X11/xdm/authdir/authfiles/A:2-m4dRq1 root 30746 7954 7 Jul29 tty9 10:55:20 /usr/bin/X -nolisten tcp -br :1 vt9 -auth /etc/X11/xdm/authdir/authfiles/A:1-f8qrQ9
I do not start "gnome" (gnome-session and its children). This is all done behind the scenes following the login to the X-server. I (or init, via "/etc/init.d/xdm start") starts "/usr/bin/xdm" (PID=7954). That is the parent xdm process (which produces /var/log/xdm.log). That in turn seems to start two processes for each virtual terminal enabled in Xservers -- /usr/bin/X and -:1 (xdm). The gnome-session is the child of the -:1 (xdm) process. So I would suspect that the sequence is: /etc/init.d/xdm start -> /usr/bin/xdm -> various display managagers (/usr/bin/X) paired with /usr/bin/xdm processes for each display which are responsible for accepting the login information and starting the gnome-session. Looking at the file dates under /etc/X11/xdm vs. /etc/X11/gdm -- xdm/Xsession dates to June 15 2006 while it looks like the gdm/PreSession, PostSession and Xsession files date to June 9 2009 (less than 2 months old). If gnome-session requires some special (DBus, etc.) setup now, it may not have made it back into the xdm/Xsession file (i.e. running gnome sessions directly from xdm is problematic). The bug here would be that gnome-session isn't making sure that it has a fully functional environment (which may in turn explain the metacity & gnome-panel workspace name problems).
The file /etc/conf.d/xdm, was last modified May 25, 2009. It sets "DISPLAYMANAGER=xdm". Though I have copies of that file which also set DISPLAYMANAGER=xdm dating back to November 2007. The errors at the start of .gnomerc-errors may be helpful, they are: which: no keychain in (:/home/bradbury/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.3.3:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/ usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/usr/GNUstep/System/Tools:/usr/GNUstep/Local/Tools:/usr/java/bin:/home/bradbury/Genomes/bin) /etc/X11/xinit/xinitrc.d/50-ssh-agent: line 5: gdmwhich: command not found /etc/X11/Sessions/Gnome: ssh-agent not found! Looking at the files in /etc/X11/xinit/xinitrc.d, it looks like 49-keychain and 50-ssh-agent may be recent additions which may have gdm dependencies. The problems may not occur for someone running gnome-session under gdm.
could you focus on answering my questions before filling tens of comments ? TIA.
ok so you are starting gnome via xdm so it uses the actual /etc/X11/Sessions/Gnome file to start it, perfect. Now according to your ps output, you do not have a dbus system instance. Fixing that would be a first step in the right direction (adding dbus to your runlevels) since most of gnome heavily relies on the presence of both a session and a system bus.
The ps --forest did not capture the dbus entries (because they are children of init I think). Slightly edited, ps entries for dbus are: 98 7298 1 0 Jul28 ? 00:00:10 /usr/bin/dbus-daemon --system root 8150 1 0 Jul28 ? 00:00:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session root 8151 1 0 Jul28 ? 00:00:01 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session bradbury 32430 1 0 Jul29 ? 00:00:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session bradbury 32431 1 0 Jul29 ? 00:00:01 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session firefox 31967 1 0 Aug05 ? 00:00:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session firefox 31968 1 0 Aug05 ? 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session I'm not sure why ps doesn't list UID 98 as "messagebus" unless it is due to the length (the entries are in /etc/passwd & /etc/shadow). I have discovered and fixed two problems in /etc/X11/xinit/xinitrc.d 1) 50-ssh-agent called "gdmwhich" (which is undefined). Changed to call "which". 2) 90-consolekit did not have the execute bits set as requested by the emerge output. Also fixed. These changes fixed the "gdmwhich: command not found" error in .gnomerc-errors but don't seem to have fixed the other problems. (Just as an FYI, though I record, I rarely read the daily emerge update output files -- at a rate of 2-5 updates per day this could easily suck down an hour or two every morning. Gentoo really needs a way to push the critical pre-emerge warnings, post-emerge user interventions into email messages which the use might pay attention to.) I do however agree with various comments that suggest that I've got some kind of dbus/messagebus (don't understand the difference) problem. Right now I would lay bets that its because something isn't set properly in the xdm -> gnome-session startup vs. the gdm -> gnome-session startup but I haven't yet verified that. (Also FYI, I'm not trying to be difficult in responding to information requests, but when I'm dealing with the Firefox, Gentoo and Gnome databases simultaneously I may be dealing with other bugs when the requests are made -- bug investigations tend to be kind of "batch" approach for me.)
I am currently leaning in the direction that this is a combination bug between gnome-session upgrades (-2.26.X?) [using ConsoleKit], consolekit upgrades (-0.3.0? from 090412?), and openrc/xdm (esp. /etc/init.d/xdm). The fact that /usr/sbin/console-kit-daemon was not running on my system (in spite of the fact that it was on the "use" list in /etc/init.d/xdm) AND the fact that consolekit isn't in any /etc/rc.d/* directory AND the fact that the .gnomerc-errors regarding "Could not connect to ConsoleKit" went away, once consolekit was explicitly started and a gnome-session restarted suggest to me that somewhere in the upgrade process someone missed the fact that gnome-session now appears to require consolekit be started before one attempts to use the gnome session. It is questionable (to me) that the xdm actually requires consolekit -- it may only be a requirement for *some* of the window managers that run under X to have the console-kit running. If so, then the problem may revolve around the fact that /etc/X11/xinit/xinitrc.d/90-consolekit, appears to set "STARTUP" to /usr/bin/ck-launch-session but that it does not in turn appear to be used anywhere (at least under /etc/init.d or /etc/X11). Though I've only looked at the strings in ck-lanuch-session it doesn't appear that it attempts to start the console-kit-daemon which apparently gnome-session requires). So the problem appears to revolve around the fact that /etc/init.d/xdm does not have an "after consolekit" command. Nor indeed should it, if gnome-session is the only X based wm which requires it! So the weight falls on either some explicit message in the consolekit | gnome-session upgrade that indicates that /etc/rc.d/* subdirectories must be modified to include consolekit for specific init states, or the gnome-session startup itself should either refuse to start without consolekit-kit-daemon or there should be explicit documentation that it is *required* for a gnome-session to function reliably. Errors in .gnomerc-errors regarding "ConsoleKit" and "org.freedesktop.ConsoleKit" are not likely to send people off looking for the strings "consolekit" in their package install records or "console-kit" in their ps output! I have not yet, and may not for several days, try rebooting the system into state 3 (consoles), explicitly trying "/etc/init.d/consolekit start" before shifting to state 5 (which starts xdm) to see if that solves all the problems. But Gentoo folks using gnome might want to stop the console-kit-daemon and see what starts breaking (esp. for a new gnome session with no consolekit running). Bug reports with the various gnome package developers about the non-standard and less than usefully informative error messages (when consolekit is unavailable) might also be called for.
no matter what I do, starting a gnome session with gdm gets me a consolekit-daemon. I'll try to install xdm and see if I get anything weird.
please get back to us.
For this specific bug, it appears to be resolved by ensuring that one has the "console-kit-daemon" as root as a child of init. One should be able to reproduce it by simply stopping consolekit (/etc/init.d/consolekit stop [1,2]) and attempting to start normal desktop sessions. The problem may be associated with the fact that the "ConsoleKit" (a.k.a. consolekit) messages do not make it clear that one *must* update ones various initstates (in my case, state "5" which is my "windows" state) using rc-update or by simply creating the symlink "/etc/rc.d/windows/consolekit" to "/etc/init.d/consolekit") so that the consolekit daemon will be started when one reboots the system and transitions to ones "windows/xdm/gdm/etc." state. This is separate from the fact that one of the down-sides of the overall Gentoo system maintenance problem is that one has to actually read the "Messages" after every upgrade and know how to interpret them. The messages aren't always user-friendly (as is the case here). It would also be helpful if there were an emerge option that would send an email to the system administrator (which may be offsite -- someplace like gmail) a message regarding "critical" upgrade Messages (vs. "informational" messages) since people may perform semi-automated package upgrades nightly (I'd say ~80-90% of upgrades fall into the category of upgrade and ignore) but only look at the Messages when it is absolutely necessary (perhaps weeks later). It would also be nice if upgrades could be separated into "can break a package", "can break multiple packages", "can break critical system components" (e.g. X, gdm, etc.) and "can prevent system from booting" (as was the case with a recent e2fsprogs upgrade and in past times the openrc and udev upgrades have been), so a semi-automated upgrade process could separate the "upgrade and ignore" from the "upgrade only if you have several days to spend debugging it" categories. 1. Alternatively, you could "rm /etc/rc.d/*/consolekit" and reboot your system and see how the window managers function. 2. I do note that "/etc/init.d/xdm" does seem to have a dependency on "consolekit". I am unsure whether it is the case that init dependencies work correctly if one uses sequenced boot states, e.g.: (default (3) --> windows (5)) as I do(!). The moddate on /etc/init.d/xdm is Feb 10, 2009, so it hasn't been changed recently -- but the problem didn't seem to go away until I updated my /etc/rc.d/windows directory to have the "consolekit" link. There may be some kind of problem in init that the init script dependencies ("use" packages) do not work if the package names are not also linked into specific initstates -- or perhaps "use" options are ignored going from the default state to some other state). In which case this is an init/openrc bug and has little to do with consolekit, gdm, xdm, etc. But it would be useful if gnome-session made an explicit test to make sure console-kit was alive and functioning and gave an explicit warning that sessions would not work properly without it. It would also be nice if consolekit could be done away with and gnome would still work properly (that does not appear to be the case at this time). The general Gnome development path seems to be following in the footsteps of KDE -- lots more bells and whistles where the overhead and details which must be learned by the end-user hardly seem justified in terms of additional "really useful" functionality.
(In reply to comment #15) > This is separate from the fact that one of the down-sides of the overall Gentoo > system maintenance problem is that one has to actually read the "Messages" > after every upgrade and know how to interpret them. The messages aren't always > user-friendly (as is the case here). It would also be helpful if there were an > emerge option that would send an email to the system administrator (which may > be offsite -- someplace like gmail) a message regarding "critical" upgrade > Messages (vs. "informational" messages) since people may perform semi-automated > package upgrades nightly (I'd say ~80-90% of upgrades fall into the category of > upgrade and ignore) but only look at the Messages when it is absolutely > necessary (perhaps weeks later). that's called ELOG, see http://blogs.gentoo.org/index.php/2009/08/04/on-elog?blog=86 > It would also be nice if upgrades could be separated into "can break a > package", "can break multiple packages", "can break critical system components" > (e.g. X, gdm, etc.) and "can prevent system from booting" (as was the case with > a recent e2fsprogs upgrade and in past times the openrc and udev upgrades have > been), so a semi-automated upgrade process could separate the "upgrade and > ignore" from the "upgrade only if you have several days to spend debugging it" > categories. Upgrades are supposed to be attended to handle at least the config files updates. There is no way around it, if you don't like it, well bad luck that's not how gentoo works. For other kind of breaks, please contact maintainers of related packages, this bug is not the place for general complaints. > 2. I do note that "/etc/init.d/xdm" does seem to have a dependency on > "consolekit". I am unsure whether it is the case that init dependencies work > correctly if one uses sequenced boot states, e.g.: (default (3) --> windows > (5)) as I do(!). The moddate on /etc/init.d/xdm is Feb 10, 2009, so it hasn't > been changed recently -- but the problem didn't seem to go away until I updated > my /etc/rc.d/windows directory to have the "consolekit" link. There may be > some kind of problem in init that the init script dependencies ("use" packages) > do not work if the package names are not also linked into specific initstates > -- or perhaps "use" options are ignored going from the default state to some > other state). In which case this is an init/openrc bug and has little to do > with consolekit, gdm, xdm, etc. But it would be useful if gnome-session made > an explicit test to make sure console-kit was alive and functioning and gave an > explicit warning that sessions would not work properly without it. It would > also be nice if consolekit could be done away with and gnome would still work > properly (that does not appear to be the case at this time). The general Gnome > development path seems to be following in the footsteps of KDE -- lots more > bells and whistles where the overhead and details which must be learned by the > end-user hardly seem justified in terms of additional "really useful" > functionality. > nothing forces consolekit in gnome land, if somethings fails without it, just report it and we will have a look at it.
closing worksforme, I lost track and what was really wrong in the prose and don't have time to spend on this anymore. If you must reopen because you still have a problem please keep your answer in less than five lines.
