GNOME Bugzilla – Bug 572027
gconf-sanity-check-2 exits with status 256
Last modified: 2013-01-22 01:10:00 UTC
Please describe the problem: I've just upgraded gconf to version 2.25.1 on 3 boxes. When I start gnome, I get a popup saying: "There is a problem with the configuration server (path.../gconf-sanity-check-2 exited with status 256)" Once I press the OK button, gnome starts as usual and everything seems to work properly from there on. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
I just upgraded to 2.26.0 (on 3 different machines). The problem is still here.
I found why that happens, because /etc/gconf/gconf.xml.system is installed with wrong permissions (not readable by users) Changing permissions will fix it
Interesting. I'm building gnome under garnome, which means that things get mapped (in my case) to /opt/gnome/... In any event, "find -name gconf.xml.system -ls" shows no hits in either /opt/gnome/etc and/or /etc.
I just checked my logs, GConf in fact doesnt install that dir. searching through ALL logs, no application installs that dir, its actually still blank, I assume some app created it possibly when i ran it as root. try running gconf-sanity-check-2 in console before starting X thats how i found my solution
I experience the same issue, and here is the problem (and the bug) and the solution to it before it is fixed in the packaging. It affects anyone installing gnome with other than a /etc value for sysconfdir, such as garnome. The problem is that gconf-sanity-check-2 always expects there to be a /etc/gconf/gconf.xml.system directory, irrespective of whether /etc is really the GConf sysconfdir value. This obviously only works if the gnome syscondir value is indeed /etc, because otherwise /etc/gconf will not exist. The solution is to create to symbolic link from /etc/gconf to the real gconf directory (eg /opt/gnome/etc/gconf), and then in /opt/gnome/etc/gconf create an empty gconf.xml.system directory with world-readable permissions. The latter seems a pretty pointless exercise because I am not aware of anything that uses gconf.xml.system, but it shuts gconf-sanity-check-2 up. There is a further sub-oddity, namely that if gconf-sanity-check-2 does not find a /etc/gconf/gconf.xml.system directory, but finds a /etc/gconf directory, then it will try to create /etc/gconf/gconf.xml.system. This of course will only work if gconf-sanity-check-2 is run as root, which normally it isn't. However, if run as root, the /etc/gconf/gconf.xml.system directory it creates is only root readable, which gconf-sanity-check-2 also objects to when subsequently not run as root, such as on gnome start-up. GConf seems to exhibit a rats-nest of odd behaviour, presumably because different bits have been cobbled together at different times in different ways and it no longer exhibits any consistent behaviour. You will also find that if run from the command line without X running, its first guess at the problem is that there is a file locking issue, which is wrong.
Created attachment 136372 [details] [review] Use sysconfdir instead of /etc (In reply to comment #5) "Assumes /etc is sysconfdir" sounds like a separate broken-ness. It also affects anyone who doesn't have gnome on the base system and wants to keep third-party configs separate or has a pure-user-land install. This path is hardcoded in gconf/default.path.in, so the solution is to substitute ${sysconfdir} there via sed in gconf/Makefile.am (just like how ${sysgconfdir} is for a different purpose). This patch solves it for me.
Created attachment 136378 [details] [review] pref-dirs.patch (In reply to comment #5) > There is a further sub-oddity, namely that if gconf-sanity-check-2 does not > find a /etc/gconf/gconf.xml.system directory, but finds a /etc/gconf directory, > then it will try to create /etc/gconf/gconf.xml.system. This of course will > only work if gconf-sanity-check-2 is run as root, which normally it isn't. > However, if run as root, the /etc/gconf/gconf.xml.system directory it creates > is only root readable, which gconf-sanity-check-2 also objects to when > subsequently not run as root, such as on gnome start-up. The other gconf.xml.* config dirs are created during 'make install'. Top-level Makefile.am has: install-data-local: -mkdir -p $(DESTDIR)$(sysgconfdir)/gconf.xml.defaults -chmod 755 $(DESTDIR)$(sysgconfdir)/gconf.xml.defaults -mkdir -p $(DESTDIR)$(sysgconfdir)/gconf.xml.mandatory -chmod 755 $(DESTDIR)$(sysgconfdir)/gconf.xml.mandatory so could just add: -mkdir -p $(DESTDIR)/etc/gconf/gconf.xml.system -chmod 755 $(DESTDIR)/etc/gconf/gconf.xml.system to that block (or ${sysconfdir} instead of /etc per Comment #6) or added as an install-data-local to gconf/Makefile.am. Not quite sure why the dirs are created in a different level of makefile than where the code that handles them is, but whatever. Further, given that gconf-sanity-check-2 complains loudly if these dirs are not present and creates them in a way that is also not correct, I think the creation should *not* be optional/allowed-to-fail (no "-" prefix). Attached patch fixes all this (NB, Comment #6 patch was to Makefile.in not Makefile.am)
Any chance Daniel's patch might be committed, perhaps in time for Gnome 2.30? Sure, the bug is easy to work around in packaging, but it really should be installed correctly to start with.
Hello everybody, I have a similar problem except that /etc/gconf/gconf.xml.system exists and has the right permissions: [pavel@ibm-pavel ~]$ ll -d /etc/gconf/gconf.xml.* drwxr-xr-x 2 root root 4096 2011-02-10 07:08 /etc/gconf/gconf.xml.defaults/ drwxr-xr-x 5 root root 4096 2010-11-05 21:02 /etc/gconf/gconf.xml.local-defaults/ drwxr-xr-x 2 root root 4096 2010-03-30 15:57 /etc/gconf/gconf.xml.local-mandatory/ drwxr-xr-x 2 root root 4096 2010-03-30 15:57 /etc/gconf/gconf.xml.mandatory/ drwxr-xr-x 2 root root 4096 2010-11-07 17:01 /etc/gconf/gconf.xml.system/ The problem must lie somwhere else. I run Mandriva 2010.2 on i586, gconfmm2.6-2.28.0-2mdv2010.1 and gdm-2.30.2-12mdv2010.1.