Bug 717804 - gconf schema updates (such as those in package installs) take far too long (Rawhide / F16)
Summary: gconf schema updates (such as those in package installs) take far too long (R...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: GConf2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-29 23:21 UTC by Adam Williamson
Modified: 2012-02-14 01:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-14 01:16:03 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.