Bug 840991 - dconf + gsettings-* looping over numlock state
dconf + gsettings-* looping over numlock state
Product: Fedora
Classification: Fedora
Component: dconf (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-07-17 15:54 EDT by Nicolas Mailhot
Modified: 2013-04-08 16:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-08 16:03:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2012-07-17 15:54:13 EDT
Description of problem:

I got used years ago to wake up my systems by pressing num lock twice

(because Linux systems do not like to be woken up with the mouse, and double num lock is a no-op on all operating systems)

With gnome3 that sends dconf and gsetting-daemon in a loop

(something gnome-side wants to interpret the num-lock, wakes up too late, and then tries desperately to reset a state which already changed)

The symptoms change over time but are all horrible:
- severe disk trashing as dconf state is rewritten serially (that seems to be mitigated by tmpfs on /tmp lately)
- input system too busy to accept new typing
- keyboard killed as the kernel inserts new numlock led state changes too fast for the usb queue to process

Nowadays when I log in on gnome3 I have to remember to open a term and kill dconf + gsettings-*  processes before the system gets totally un-responsive

Sometimes I also need to unplug the keyboard physically to force things to settle down long enough before the killing (if I just re-plug the keyboard the mess starts again)

I have to remember not to use the numlock keys as they are not reliable anymore – if I try to use during such an incident, bad things happen when . changes to del and 0 to insert randomly

This is quite broken. Please stop messing with num lock that didn't ask anything of gnome

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Press num lock twice rapidly to wake up gdm or the lock up screen
Actual results:
A mess

Expected results:
Screen lits up because of keyboard activity (and nothing else)

Additional info:
$ setxkbmap -print | grep xkb_symbols
	xkb_symbols   { include "pc+fr(oss)+in(mal):2+us:3+inet(evdev)+terminate(ctrl_alt_bksp)"	};
Comment 1 Fedora End Of Life 2013-04-03 12:10:18 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
Comment 2 Matthias Clasen 2013-04-08 16:03:14 EDT
This was fixed in gnome-settings-daemon

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