After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 95179 - gnome-settings-daemon needlessly slowing down login by synching gconf database
gnome-settings-daemon needlessly slowing down login by synching gconf database
Status: RESOLVED INCOMPLETE
Product: gnome-control-center
Classification: Core
Component: [obsolete] settings-daemon
2.2.x
Other All
: Normal minor
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-10-08 13:11 UTC by Brian Cameron
Modified: 2007-07-29 20:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Brian Cameron 2002-10-08 13:11:37 UTC
A number of gconf keys are set by the gnome-settings-daemon at login
time, which causes the gconf database to get synched.  This slows things
down.  

This window_manager keys get set:

/desktop/gnome/applications/window_manager/default

Furthermore, the following a11y-related gconf keys are set during login. 
According to Jody Goldberg (on gnome-hackers list), "This is a side
effect of monitoring the XKB state in the server, when we load the values
from gconf it triggers an event from the X server which causes us to
reload from the X server.  It should not be hard to notice that the X
server is not changing any gconf state and avoid doing the assignment."

It would speed login if these keys were not written at every login (and
the resulting gconf sync were avoided) except when the values have
changed and require updating gconf.  In the general case, the values are
just updated with the same values that were there before.

 --list of keys currently being written--

 /desktop/gnome/accessibility/keyboard/enable
 /desktop/gnome/accessibility/keyboard/feature_state_change_beep
 /desktop/gnome/accessibility/keyboard/timeout
 /desktop/gnome/accessibility/keyboard/bouncekeys_delay
 /desktop/gnome/accessibility/keyboard/bouncekeys_beep_reject
 /desktop/gnome/accessibility/keyboard/mousekeys_max_speed
 /desktop/gnome/accessibility/keyboard/mousekeys_accel_time
 /desktop/gnome/accessibility/keyboard/mousekeys_init_delay
 /desktop/gnome/accessibility/keyboard/slowkeys_beep_press
 /desktop/gnome/accessibility/keyboard/slowkeys_beep_accept
 /desktop/gnome/accessibility/keyboard/slowkeys_beep_reject
 /desktop/gnome/accessibility/keyboard/slowkeys_delay
 /desktop/gnome/accessibility/keyboard/stickykeys_two_key_off
 /desktop/gnome/accessibility/keyboard/stickykeys_modifier_beep
 /desktop/gnome/accessibility/keyboard/enable
 /desktop/gnome/accessibility/keyboard/feature_state_change_beep
 /desktop/gnome/accessibility/keyboard/timeout
 /desktop/gnome/accessibility/keyboard/bouncekeys_delay
 /desktop/gnome/accessibility/keyboard/bouncekeys_beep_reject
 /desktop/gnome/accessibility/keyboard/mousekeys_max_speed
 /desktop/gnome/accessibility/keyboard/mousekeys_accel_time
 /desktop/gnome/accessibility/keyboard/mousekeys_init_delay
 /desktop/gnome/accessibility/keyboard/slowkeys_beep_press
 /desktop/gnome/accessibility/keyboard/slowkeys_beep_accept
 /desktop/gnome/accessibility/keyboard/slowkeys_beep_reject
 /desktop/gnome/accessibility/keyboard/slowkeys_delay
 /desktop/gnome/accessibility/keyboard/stickykeys_two_key_off
 /desktop/gnome/accessibility/keyboard/stickykeys_modifier_beep
Comment 1 Jody Goldberg 2002-10-08 16:35:35 UTC
Actually there was an even earlier thinko that was causing this.  We were
installing the monitoring filter _before_ we assigned the gconf values to the x
server.  However, I had already coded up the more difficult test, so both fixes
can go in.

patch applied to both branches.
Comment 2 Brian Cameron 2002-10-10 13:06:44 UTC
The patch gets rid of all the a11y keys, but this one is still being
written to, so the gconf sync is still happening:

  /desktop/gnome/applications/window_manager/default

Can this one be eliminated as well?
Comment 3 Jody Goldberg 2002-10-10 13:40:58 UTC
I'll have a look today.
Comment 4 Luis Villa 2002-12-06 20:33:24 UTC
Jody, can you take care of this last one?
Comment 5 Kjartan Maraas 2004-01-11 14:48:54 UTC
Jody, did you ever take a look at this? Is it still relevant?
Comment 6 Jody Goldberg 2004-01-12 19:41:35 UTC
Still relevent
Didn't look
Comment 7 Vincent Noel 2004-08-09 19:39:16 UTC
ping : can someone approve this (very small) change ?
Comment 8 Behdad Esfahbod 2005-11-08 19:09:28 UTC
ping again.
Comment 9 Federico Mena Quintero 2006-01-05 01:06:00 UTC
Ping yet again.
Comment 10 Rodrigo Moya 2006-01-05 11:04:43 UTC
Vincent, Jody, can you enlighten me on what the change is? I didn't see the original patch Jody 'applied to both branches', so I'm not really sure what the change was.
Comment 11 Nelson Benitez 2006-10-16 12:40:33 UTC
Rodrigo, these[1] are the changes that Jody commited, hope this is useful for you.

[1] http://tinyurl.com/yac5x4  (thanks Bonsai)
Comment 12 Jens Granseuer 2007-02-19 18:33:38 UTC
I can't see where the current code would try to touch the window_manager setting. If this is still relevant could somebody please supply that bit of info?
Comment 13 Jens Granseuer 2007-07-29 20:05:58 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!