Results 1 to 4 of 4

Thread: Firefox Gconf Problem

  1. #1
    mingus Guest

    Default

    Using SUSE 64-bit w/32-bit Firefox (don't think this is a 64-bit problem) . . .

    After installing/upgrading other software (I was cleaning up after a 32-to-64 bit re-install, so not sure exactly which pkg did this, my guess is CompizFusion), upon loading Firefox it returns a "server not found" error.

    Running Firefox --verbose from the shell, I get the error:

    GConf Error: Failed to launch configuration server: Failed to execute child process "/opt/gnome/lib/GConf/2/gconfd-2" (No such file or directory)

    I have tried uninstalling & reinstalling Firefox, plus both gconf2 packages - no help.

    EDIT: With more investigation I found that the gconf2 pkg i586 vsn installs to /opt/gnome. I have an old 32-bit 10.2 on another partition, so I copied the file over. Now Firefox does not return any errors to the shell, but the browser still returns "server not found" and just waits. I didn't touch the Firefox config, it looks fine.

    EDIT: I installed from the tar into a /home directory. Same error! Gnome is not in the system requirements, and anyway, whatever is needed should be in the tar. So it seems that something is incorrectly pointing Firefox to /opt/...gconfd-2. I'll check the Firefox forums and bugzilla . . .

  2. #2
    Sven Guest

    Default

    I was also having the same problem with Firefox (and Gizmo) complaining that they needed gconfd. Like your situation, it seemed to happen after a recent CompizFusion update.

    On my (64 bit) system, gconfd-2 is currently installed in the /usr/lib/GConf/2/ directory, while Firefox and Gizmo seemed to be looking for it in /opt/gnome/lib/GConf/2/. I created a sym link to the gconfd-2 binary within the /opt/... directory & everything seems to be working fine now.

    Since gconfd automatically shuts down when not in use, then starts up when needed . . . I'm guessing that I didn't see this problem before since my original Compiz install was using Gconf which kept gconfd alive. Now, I have CompizFusion set to use the flat file method, so gconfd shuts down since nothing (in KDE) needs it.

    Could the "server not found" error be a separate networking/DNS resolution issue?

  3. #3
    mingus Guest

    Default

    I was also having the same problem with Firefox (and Gizmo) complaining that they needed gconfd. Like your situation, it seemed to happen after a recent CompizFusion update.

    On my (64 bit) system, gconfd-2 is currently installed in the /usr/lib/GConf/2/ directory, while Firefox and Gizmo seemed to be looking for it in /opt/gnome/lib/GConf/2/. I created a sym link to the gconfd-2 binary within the /opt/... directory & everything seems to be working fine now.

    Since gconfd automatically shuts down when not in use, then starts up when needed . . . I'm guessing that I didn't see this problem before since my original Compiz install was using Gconf which kept gconfd alive. Now, I have CompizFusion set to use the flat file method, so gconfd shuts down since nothing (in KDE) needs it.

    Could the "server not found" error be a separate networking/DNS resolution issue?
    [/b]
    I tried the symlink as well, didn't work. Copied the file from a 32-bit instance and the gconfd-2 error went away, but Firefox still couldn't resolve. Definitely not a DNS or network config prob. However, your point re the CompizFusion backend got me thinking . . .

    I am using the KDE backend, not the flat file. The former allows me to shutdown the system without locking up (I use Nvidia & Xorg, not Xgl), while the flat file does not. But I can work around this if necessary.

    There is something very strange with Firefox and gconf. Firefox should not need it; other users don't have any gnome bits at all (except gtk) and no problem. I installed Firefox from source in a ~/directory, and got the same error. But googling and reading the Firefox startup script, it appears that Firefox scans the system and sets up environment variables based on what it finds. I think that CompizFusion or another gnome-based app may have put something under ~/.gconf that Firefox is picking up. I'm away from my system until the week-end. I'll check out all these possibilities then.

    Thx again for the suggestions.

  4. #4
    mingus Guest

    Default

    I finally have solved - well, sort of solved - the problem . . . actually, there were two problems. I'm including this explanation for the benefit of other users who may encounter these:

    First, there *is* a gconf dependency in Firefox, but it is a "soft" dependency. While Firefox may not be actively using gconf2, it definitely now looks for and executes it if found. I found Mozilla dev posts that discussed having integrated Firefox with both the gconf (gnome config database) and gnomevfs (virtual file system) libraries. In the SUSE rpm, gconf2 is listed as a dependency. When either Firefox 32-bit or 64-bit is executed, it invokes the gconf2 daemon (gconfd-2). On SUSE, the 32-bit looks for the file under /opt/gnome/ while the 64-bit looks for it under /usr/lib/ (note: not /usr/lib64/). In Ksysguard you see gconf2 spawned by Firefox (if gconf2 is there); a few moments after closing Firefox gconf2 closes down. It seems it is there as a developer's option; on my system, the gconf database is empty, it is not being used for anything. This is not a SUSE-only thing. In the Mozilla .tar installation, having moved out the previous ~/.mozilla profile folder so that it gets re-created, Firefox still calls gconf2. There are also two libraries in the .tar that apparently are there in the event that gconf or gnomevfs is being used; they are in the /components folder as libmozgnome.so and libnkgnomevfs.so. They can be removed and Firefox still runs fine, but it still calls gconfd-2. So my specific problem was apparently caused by somehow loosing a symlink (despite an rpm re-install of the 32-bit) from /usr/lib/ to /opt/gnome/ where the 32-bit version, both the rpm and the Mozilla .tar, look for it. Adding the symlink solved the "missing gconfd-2" error.

    Although the second problem appeared at the same time as the first, it seems completely unrelated: Regardless of the above one way or the other, after installing the 64-bit vsn of Firefox, and also after re-installing the 32-bit vsn both rpm and tar, and again having removed ~/.mozilla, Firefox could not resolve DNS. There is a Firefox config preference called network.dns.disableIPv6 which is set to "false". (Supposedly the default is "true"; given that I removed ~/.mozilla before in-installing, which removed the preferences file, it appears that Firefox upon first start looks to see if IPv6 is installed on the system and if so, sets the pref to "false"; the IPv6 module is loaded on my system.) But for a reason I have not been able to figure out yet, my 32-bit installations (both rpm and tar) fail to resolve DNS unless this preference is changed back to "true" - while my 64-bit Firefox doesn't care; it resolves whether the setting is false or true (of course using the same network configuration). So changing this pref to "true" eliminated the DNS problem in the 32-bit Firefox.

    Thx again for taking the time to help.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Search Engine Friendly URLs by vBSEO 3.5.2