GNOME Bugzilla – Bug 74135
Building apps using GConf2 fails due to %gconf-xml-backend.lock/ior
Last modified: 2009-08-15 18:40:50 UTC
When trying to build Rhythmbox (rhytmbox-new from CVS) I often get the following GConf error: mkdir /var/tmp/rhythmbox-0.1-root/usr/share/pixmaps /usr/bin/install -c -m 644 rhythmbox.png /var/tmp/rhythmbox-0.1-root/usr/share/pixmaps/rhythmbox.png GCONF_CONFIG_SOURCE=xml::/etc/gconf/gconf.xml.defaults /usr/bin/gconftool-2 --makefile-install-rule rhythmbox.schemas Failed to access configuration source(s): Failed to lock '/etc/gconf/gconf.xml.defaults/%gconf-xml-backend.lock/ior': probably another process has the lock, or your operating system has NFS file locking misconfigured (Resource temporarily unavailable) make[2]: *** [install-schemas] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/rhythmbox-0.1' make[1]: *** [install-am] Error 2 I am using a ordinary local RH7.2 install using ext2. Deleting the ior file solves the problem for that compile, but as it keeps coming back I feel it is a bug that needs relsolving as it probably will make compiling a lot of GNOME2 software a hassle.
I think something is wrong with your system or with rhythmbox's setup - this doesn't happen for any of the other gnome apps that install schemas, does it?
i really dont see how this oculd be caused by rhythmbox - afaics we do nothing special, this is all we do, like all other apps: install-schemas: $(SCHEMAS_FILE) GCONF_CONFIG_SOURCE=$(GCONF_SCHEMA_CONFIG_SOURCE) $(GCONFTOOL) --makefile-install-rule $(SCHEMAS_FILE)
I have other parts of GNOME2 installed like gnome-utils but didn't experience this problem no. But then again Rhythmbox is the only GNOME2 application I have been rebuilding many times a day. I must stress that I don't always get this problem, just sometimes, like say 1 in 5.
So the issue is probably that another process has the lock; the question is what other process and why. Normally gconfd does not lock the "defaults" backend - it uses it in read-only mode. But when installing schema files it's locked by the gconftool doing the installation. If you re-run the make does it usually work the second time? If not, can you try "ps jaxwww | grep gconf" to look for other processes? Maybe try "fuser" on the lock file to see who has it open?
What's the status on this bug? It's sort of cluttering my queries and has been sitting here for a long time :) Marking NEEDINFO since Havoc seems to have asked some unanswered questions of Jorn...
No I think he is asking me, but I have not had this bug lately. Either it is fixed or I did something weird at the time. I am closing it :)