Bug 717804

Summary: gconf schema updates (such as those in package installs) take far too long (Rawhide / F16)
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: GConf2Assignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: mclasen, rstrode, walters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-14 01:16:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Adam Williamson 2011-06-29 23:21:46 UTC
While updating from F15 to current Rawhide (F16) on an extremely fast machine, I noticed some packages still took a very long time to install. I isolated this to gconf schema updates which are required in the %pre and %post of packages which ship gconf schemas. During the upgrade, and on the updated system, these commands take a long time to complete.

Easily reproducible on my systems simply by running this command (obviously, with Evolution installed):

GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule /etc/gconf/schemas/apps-evolution-mail-notification.schemas

this is taken directly from the Evolution spec file. On my now-updated-to-Rawhide box, it takes a minute to complete - when run it simply sits there with no feedback for a minute, then quickly spits out the 'Attached schema' and 'Install schema' messages and finishes. Interestingly, if I feed it an incorrect path to the .schemas file, it still sits there for a minute, apparently doing nothing, before it errors out.

If I run the exact same command on my laptop, which is still running F15, it completes virtually instantaneously, with all the console output. There is no one-minute delay during which it seems to do nothing.

Oddly, if I run it inside gdb to try and see what it's doing while sitting there, it works instantly - there is no one-minute delay.

If I run the command outside of gdb and then attach to the process with gdb, the backtrace I get is:

#0  0x0000003e7fcd74f3 in __poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x0000003e7f843d98 in g_main_context_poll (n_fds=1, fds=0x13e56b0, priority=<optimized out>, timeout=25000, 
    context=0x13e50a0) at gmain.c:3441
#2  g_main_context_iterate (context=0x13e50a0, block=<optimized out>, dispatch=1, self=<optimized out>)
    at gmain.c:3123
#3  0x0000003e7f8445d5 in g_main_loop_run (loop=0x13e5190) at gmain.c:3336
#4  0x0000003e830b223d in g_dbus_connection_send_message_with_reply_sync (connection=0x13db010, message=0x13df9e0, 
    flags=G_DBUS_SEND_MESSAGE_FLAGS_NONE, timeout_msec=-1, out_serial=0x0, cancellable=0x0, error=0x7fff1e7164c8)
    at gdbusconnection.c:2019
#5  0x0000003e830b4132 in g_dbus_connection_call_sync (connection=0x13db010, 
    bus_name=0x3e830fdea2 "org.freedesktop.DBus", object_path=0x3e830fdeb7 "/org/freedesktop/DBus", 
    interface_name=0x3e830fdea2 "org.freedesktop.DBus", method_name=0x3e830fdecd "Hello", parameters=0x0, 
    reply_type=0x3e830fdd4d, flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=-1, cancellable=0x0, error=0x13db078)
    at gdbusconnection.c:5310
#6  0x0000003e830b443e in initable_init (initable=<optimized out>, cancellable=<optimized out>, 
    error=0x7fff1e7165f8) at gdbusconnection.c:2407
#7  0x0000003e830b4c41 in g_bus_get_sync (bus_type=<optimized out>, cancellable=0x0, error=0x7fff1e7165f8)
    at gdbusconnection.c:6304
#8  0x0000003e910159f4 in get_ior (failure_log=0x13c85a0, start_if_not_found=0) at gconf-internals.c:2454
#9  gconf_get_server (start_if_not_found=0, failure_log=0x13c85a0) at gconf-internals.c:2503
#10 0x0000003e91015c82 in gconf_activate_server (start_if_not_found=0, error=0x0) at gconf-internals.c:2853
#11 0x0000003e9101fd74 in try_to_contact_server (err=0x0, start_if_not_found=<optimized out>) at gconf.c:2315
#12 gconf_get_config_server (start_if_not_found=<optimized out>, err=0x0) at gconf.c:2359
#13 0x0000003e91023b63 in gconf_shutdown_daemon (err=0x0) at gconf.c:3121
#14 0x0000000000405618 in main (argc=1, argv=0x7fff1e716938) at gconftool.c:920

Comment 1 Matthias Clasen 2012-02-14 01:16:03 UTC
gconf is actively being phased out; not going to work on optimizing it at this point.