[keyboard]: gnome-settings-daemon consumes 100% cpu (and blinking numlock)

Bug #969359 reported by James on 2012-03-30
This bug affects 241 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Fix Released
High
gnome-settings-daemon (Fedora)
Won't Fix
Critical
gnome-settings-daemon (Ubuntu)
High
Unassigned
Precise
High
Unassigned
Quantal
High
Unassigned

Bug Description

Impact:
gnome-settings-daemon uses 100% cpu for ever in some cases

Test Case:
Seems to happen sometimes after docking or connecting with vnc, try to connect to the machine using a vnc client a few times and check there is no numlock cycle and cpu usage loop starting

Regression potential:
The numlock state could be wrongly set,restored on login in some cases

-----------------

Original message:
-----------------

I don't know how to reproduce this bug, but after varying amounts of normal usage of my laptop, I notice gnome-settings-daemon is consuming 100% (approx) CPU.

I am not sure how to restart gnome-settings-daemon, I tried opening a terminal and running gnome-settings-daemon again but this crashes my system - my external monitor switches off and my laptop locks up. I am able to reboot with SysRq+REISUB.

Sorry I cannot provide more information - it happens twice now, maybe someone can tell me how to get more information for the next time this happens.

$ lsb_release -rd
Description: Ubuntu precise (development branch)
Release: 12.04

$ apt-cache policy gnome-settings-daemon
gnome-settings-daemon:
  Installed: 3.4.0-0ubuntu2
  Candidate: 3.4.0-0ubuntu2
  Version table:
 *** 3.4.0-0ubuntu2 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: gnome-settings-daemon 3.4.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-20.33-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
Date: Fri Mar 30 17:16:02 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-settings-daemon
UpgradeStatus: No upgrade log present (probably fresh install)

James (jamesasgrim) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, is g-s-d the only process using cpu? what were you doing before that starting? it could be something spamming g-s-d with config changes or pulseaudio acting crazy or something ...

the stacktrace is not useful it just shows a process waiting in poll

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
James (jamesasgrim) wrote :

My normal use includes running Google Chrome, Eclipse PDT, terminal, CXOffice, Spotify/Last.fm, Pidgin, Gedit. I cannot pinpoint a particular action I'm taking that causes it, I just notice that my laptop fan is going crazy, I check the process list and gnome-settings-daemon is up there using 100%.

You mentioned it could be pulseaudio - I do listen to last.fm/Spotify (both Linux clients), so perhaps that could be the trigger?

To me it happens even after a fresh reboot before any application is started.

James (jamesasgrim) wrote :

It's just happened again.

I ran strace on it and it seems like it's in a loop doing this:

futex(0x1184820, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x1184820, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x1184820, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x1184820, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x1184820, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x1184820, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
etc.

and occasionally I see:
futex(0x1184820, FUTEX_WAKE_PRIVATE, 1) = 0

Sander Kleykens (diod631) wrote :

I'm seeing the same thing: gnome-settings-daemon consumes 100% cpu. It also keeps turning num lock on and off rapidly. The num lock toggling doesn't show a clear pattern, but it does appear to happen more often when I'm typing or using media keys (such as volume up and down).
When I kill the daemon, the num lock toggling seems to stop.

yannis (yannis-lg) wrote :

With 12.04 clean install ,
After screensaver activation :
 gnome-settings-daemon 100% cpu + high disk acces + keyboard led blinking

Sebastien Bacher (seb128) wrote :

is everybody getting there after using the screensaver?

Changed in gnome-settings-daemon (Ubuntu):
importance: Low → High
status: Incomplete → Confirmed
Sander Kleykens (diod631) wrote :

No. All I have to do is boot up ubuntu 12.04 and log in. It doesn't (always?) happen right away though, it usually starts after I've used my media keys to reduce/increase volume (that might just be a coincidence though). Logging out and back in doesn't seem to help although it does stop for as long as I'm at the login screen (I assume gnome-settings-daemon stops when you logout).

Also, the problem appears to stop after a while: gnome-settings-daemon calms down and the num lock toggling stops.

My Ubuntu box 12.04 at work has 100% cpu usage with gnome-settings-daemon, with or without screensaver. The installation is clean from today.

Regards.

Andriy Beregovenko (silentjet) wrote :

Have the same issue. How can I collect useful information?(or what info should I collect?)
Have 12.04 x86_64, Core i5 650 CPU...

testman57 (testman57fr) wrote :

Hello,

Just to chime in that I happen to observe this exact problem on a 32bit ubuntu 12.04 version...
A blank screensaver was running, but I could not say when this cpu usage appeared exactly, I will keep an eye on it...

Jaime (jaime-parada) wrote :

Hi,

     I have the same problem. My installation of Ubuntu 12.04 is fresh. The machine is a Dell Vostro 400.

I'm experiencing this problem too. On Ubuntu 11.10 - this problem only started recently however, like in the past couple of weeks maximum, perhaps it was due to the recent version of some software in apt. If someone could indicate how to provide useful information for bug I would oblige.

Sorry, I forgot to mention that I simply terminate the process and when it restarts itself it remains calm for a while. I have yet to notice a particular trigger that sets it off.

Aatish (aatish) wrote :

Same issue here, Ubuntu 12.04 on a Thinkpad X220. After resuming from suspend, the volume icon on the unity bar showed a dashed line (---), and top informed me that gnome-setting-daemon was using up more than 100% of my cpu.

Cedric Meury (cm-wurmlo) wrote :

Same problem here, after a fresh install of 12.04, one reboot and leaving the system running for several hours. kill -9 helped.

Loban Rahman (mambazo) wrote :

HP Probook 4630s, 8GB ram.

1. Can confirm gnome-settings-daemon taking 100% cpu. No other particular apps running with high CPU.
2. Can confirm the num-lock blinking rapidly.
3. Also, caps-lock sometimes gets reversed (i.e. ALL CAPS with no caps lock light, and no caps with caps lock light on.
4. Logging out and in stopped the behavior. Dunno when it might start again.

Patrick Henning (phen93) wrote :

I am also encountering this bug. For me it seems to be triggered by use of volume keys on keyboard, which correlates with what is discussed in this thread:
http://forums.fedoraforum.org/showthread.php?t=230568
A temporary workaround on fedora was to disable the media keys functionality of gnome. So I'm thinking this is an issue with gnome more so than ubuntu itself.

kamahat (kamahat) wrote :

also concerne. my computer was light on all night with nothing to do and it's th e1st consumming process, a full core for itself

John Clark (clarkjc) wrote :

When gnome-settings-daemon is doing this, I find this logged to ~/.xsession-errors continually until I kill it:

-----
(gnome-settings-daemon:2062): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed

(gnome-settings-daemon:2062): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed

(gnome-settings-daemon:2062): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed

** (gnome-settings-daemon:2062): WARNING **: Timeout was reached

** (gnome-settings-daemon:2062): WARNING **: Timeout was reached

** (gnome-settings-daemon:2062): WARNING **: Timeout was reached
-----

Greg Grimes (thespis) wrote :

I too am seeing this bug. I noticed that I had the Ubuntu One application open when it was going crazy. I closed that app and killed the process(not sure if I really needed to do that) and the symptoms went away. Hope this might help.

156 comments hidden view all 220 comments

Created attachment 582274
htop

155 comments hidden view all 220 comments
kamahat (kamahat) wrote :

I've got the same issue with 2 differents computers on precise 12.04
gnome-settings-daemon saturated one core à 100%

Here is the result of : sudo strace -p 2425 -f -o temp/gnomes-settings-demon.trace

kamahat (kamahat) wrote :

The bug also seems to exist on fedora : https://bugzilla.redhat.com/show_bug.cgi?id=811902

kamahat (kamahat) wrote :

in the log of ~/.xsession-errors

(gnome-settings-daemon:2425): color-plugin-WARNING **: unable to get EDID for xrandr-DVI-I-1: unable to get EDID for output

(gnome-settings-daemon:2425): color-plugin-WARNING **: unable to get EDID for xrandr-DVI-I-2: unable to get EDID for output
07/05/2012 07:59:22 Autoprobing TCP port in (all) network interface
07/05/2012 07:59:22 Listening IPv6://[::]:5900
07/05/2012 07:59:22 Listening IPv4://0.0.0.0:5900
07/05/2012 07:59:22 Autoprobing selected port 5900
07/05/2012 07:59:22 Advertising security type: 'TLS' (18)
07/05/2012 07:59:22 Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
07/05/2012 07:59:22 Listening IPv6://[::]:5900
07/05/2012 07:59:22 Listening IPv4://0.0.0.0:5900
07/05/2012 07:59:22 Clearing securityTypes
07/05/2012 07:59:22 Advertising security type: 'TLS' (18)
07/05/2012 07:59:22 Clearing securityTypes
07/05/2012 07:59:22 Advertising security type: 'TLS' (18)
07/05/2012 07:59:22 Advertising authentication type: 'No Authentication' (1)
07/05/2012 07:59:22 Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
07/05/2012 07:59:22 Listening IPv6://[::]:5900
07/05/2012 07:59:22 Listening IPv4://0.0.0.0:5900
07/05/2012 07:59:22 Clearing securityTypes
07/05/2012 07:59:22 Clearing authTypes
07/05/2012 07:59:22 Advertising security type: 'TLS' (18)
07/05/2012 07:59:22 Advertising authentication type: 'No Authentication' (1)
07/05/2012 07:59:22 Advertising security type: 'No Authentication' (1)

(vino-server:2625): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent.

(vino-server:2625): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent.

(compiz:2568): GConf-CRITICAL **: gconf_client_add_dir: assertion `gconf_valid_key (dirname, NULL)' failed

Initializing unityshell options...done
Setting Update "icon_size"
Setting Update "show_desktop_icon"
Setting Update "num_launchers"
Setting Update "launcher_capture_mouse"

[...]
(gnome-settings-daemon:2425): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed

(gnome-settings-daemon:2425): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed

(gnome-settings-daemon:2425): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed

Mike M (mikem-6) wrote :

Hello,

Same problem here, upgrades Ubuntu 11.10 to 12.04 last week:
- /usr/lib/gnome-settings-daemon/gnome-settings-daemon using 100% CPU after back from screen-saver
- Keyboard "NumLock" blinking very fast
- If kill the gnome-settings-daemon if came back and if screen-saver runs again the bug repeats...
(my keyboard is a Dell Model: SK-8135, don't know if matters)

I also notice something strange, when running "/usr/lib/gnome-settings-daemon/gnome-settings-daemon --debug" manually I can see the output messages, and just by hitting "NunLock" on my keyboard I get the message:

"(gnome-settings-daemon:6711): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed"

Same message that keeps repeating when the gnome-settings-daemon goes crazy and start consuming 100% CPU.

Workaround?! Maybe, removing the keyboard plugin file from the g-s-d and restarting the daemon:

$ sudo mv /usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin ~/
$ kill <gnome-settings-daemon-PID>
kill it just to re-start the daemon, of if you're running by hand as me, just CTRL+C and start it again.

Well... after that I can lock the screen, let the screen-saver starts, hit "NunLock" on my keyboard and I don't get the error.
I just did that 40 minutes ago, I could be wrong, just get excited to post it because the error message when hitting "NunLock" disappeared.

Cheers!

Mike M (mikem-6) on 2012-05-10
tags: added: gnome-settings-daemon
Christian Mertes (mertes) wrote :

I experience this bug with my thinkpad-x40 too. But i can only reproduce it with this setting:

1. on my desktop (12.04) is a synergy server running (1.4.8-1~getdeb1)
2. on my laptop (12.04) is a synergy client running (1.4.8-1~getdeb1)
3. on my desktop the numlock is activated
4. I go from the desktop to the laptop via synergy and press any number from the num-pad.

Then on the laptop gsd says repetitive till i kill it:

"(gnome-settings-daemon:6711): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed"

But if i press direktly the numlock on my laptop i get only once the message for each hit an thats it.

Lealcy B. Junior (lealcy) wrote :

Same bug here. Started after I pressed the Num Lock "0" and "Del" at same time by mistake. Killing gnome-settings-daemon doesn't solve the issue because it auto run again and keeps bugging.

kamahat (kamahat) wrote :

the comment of "Lealcy B. Junior (lealcy) " make me think it has something to do with keyboard shortcut define in gnome.

When the symptom appears, the numlock of my keyboard begins to blink. If I do a [left shift]+[left control]+[num lock] it calms down for a few moment. Can someone confirm it works for him ?

I remember there is a shortcut for "using mouse with the keyboard", maybe searching around this ?

150 comments hidden view all 220 comments
149 comments hidden view all 220 comments
SlugiusRex (slugiusrex) wrote :

In my original report ( https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/990695 )

    Observed process use 100% + CPU utilization on one core for more than 30 minutes. Memory
    grew from about 200 MB to 390 MB during this 30 minute period.

     Process status was reported as "Sleeping/futex_wait_queme_me". However, as soon as I typed 'ubuntu-bug'
     in the terminal it switched to Running ~ and then dropped its CPU usage to 60% and gave back 100MB of
     memory.

     Then while typing this comment here.... it went back up to 102% and started consuming memory again.

     See attached screenshot

It could be the case that I used [CTRL ALT PRTSCRN] to take the screenshot - which made it calm down for a moment before it started going all berserk again. I have not been able to replicate the phenomena since my original report on 2012-04-28.

Mike M (mikem-6) wrote :

Hey everyone,

Just to confirm what I posted before: after removing the file "/usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin" and re-starting the gnome-settings-daemon I never had the problem again.... 4 days and all looking good!

Cheers,

kamahat (kamahat) wrote :

I've removed "/usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin" we wil see in the comming days

Nicolas Briche (nbriche) wrote :

Happens to me too; but it only started today. No idea why it didn't before (I upgraded to Ubuntu 12.04 last week). Killing gnome-settings-daemon calms the system for about ten, fifteen minutes, then it starts again.

Exact same symptoms as Mike M. in #28. I followed his advice (moved keyboard.gnome-settings-plugin, killed gsd) about twenty minutes ago, and it seems to keep. Thanks for that, Mike M.

kamahat (kamahat) wrote :

we are 3 days later and no more issues

brogliatto (brogliatto) wrote :

Hi guys,
I was experiencing the same issue with Ubuntu 12.04.
I followed Mike M (mikem-6)'s recommendation and the problem seems to be resolved.
Thanks.

Michal (michal-vanek) wrote :

Hi,

removing "/usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin" seems good, but after logout & login keyboard layout couldnt be changed/switched.
i have 2 layouts - Slovak (SK) and English (US). After plugin file deletion i was unable to switch from English to Slovak.

M.

Sebastien Bacher (seb128) wrote :

do the people having the issue use vwmare or equivalent?

one user on IRC who ran into it said:

" ![1337780712,000,xklavier_evt_xkb.c:xkl_xkb_process_x_event/] ATTENTION! Currently cached group 0 is not equal to the current group from the event: 1
 seems to be triggered by having different numlock states inside vmware and in gnome and switching between the two"

kamahat (kamahat) wrote :

>>do the people having the issue use vwmare or equivalent?

no it happends to me after a fresh new install without any virtulisation techno

142 comments hidden view all 220 comments

Created attachment 587339
backtrace for gnome-settings-daemon 1-process

Created attachment 587340
backtrace for gnome-settings-daemon 2-process

Created attachment 587342
backtrace for dconf-service process

Created attachment 587343
backtrace for dbus-daemon process

summary: - gnome-settings-daemon consumes 100% cpu
+ [keyboard]: gnome-settings-daemon consumes 100% cpu (vnp, virtualbox,
+ ...)?
Changed in gnome-settings-daemon (Ubuntu Precise):
status: New → Confirmed

Created attachment 589027
backtrace for gnome-settings-daemon

Created attachment 589028
backtrace for dconf worker process

Created attachment 589033
backtrace for Compositor

Created attachment 589035
backtrace for dconf-service

when it occurs Num Lock indicator is often blink.

summary: - [keyboard]: gnome-settings-daemon consumes 100% cpu (vnp, virtualbox,
- ...)?
+ [keyboard]: gnome-settings-daemon consumes 100% cpu (and blinking
+ numlock)
description: updated
Changed in gnome-settings-daemon (Ubuntu Precise):
importance: Undecided → High
Changed in gnome-settings-daemon (Ubuntu Precise):
milestone: none → ubuntu-12.04.1
status: Confirmed → Triaged
Changed in gnome-settings-daemon:
importance: Undecided → Unknown
status: New → Unknown
Changed in gnome-settings-daemon:
importance: Unknown → High
status: Unknown → New

Killing dconf worker process seems stop this, but something wrong after this:
Not work hot keys (Ctrl +Shift + L - lock comkputer, Prt Scr - make screenshot), decrease font...

Killing dconf worker process seems stop this, but something wrong after this:
Not work hot keys (Ctrl +Shift + L - lock computer, Prt Scr - make screenshot), decrease font...

Created attachment 597807
backtrace for dconf worker process

Created attachment 597808
proof screenshot

see also this GNOME bug: https://bugzilla.gnome.org/show_bug.cgi?id=679151

FWIW: Affects me, too. pkill -STOP gnome-settings lets me use my computer again...

Even happens during teh day when I am away for work.

killall -9 gnome-settings-daemon helps, but is it the right way?

dconf is indeed active as well. (noticed after killing)

Comment 12 was observed here as well.
Comment 14 was observed here as well.

I am on x86_64. You too?

This bug makes working cumbersome.
The machine is ok in the early morning.
I leave home for work and return after 9.5-10 hours.
gnome-settings-daemon is making the numlock blink feverishly and the system slowish.
So we kill gnome-settings-daemon.
Also we kill the dconf thing.
We log out. The machine completes slowly.
We log in and stuff is mostly fine again for the rest of the day and next morning.

But is this a nice way to work with the box?
Therefor I increased severity again.

Mikhail created a very nice bug report.
Bastien: please come and help fix this.

I tried the dconf-editor workaround from comment 17 yesterday.
Today I found my box without the blinking numlock. gnome-settings-daemon was still consuming one full core.
So we killed that stuff.
Logged out and logged in.

Can someone please fix this without mentioning the `upstream` mantra?

Sorry my previous backtraces not contain debugging symbols. Now I'm fixed.

Another well-reproduced the bug on my laptop on kitchen (it has little memory, and he constantly swaps) when I started google-chrome and evolution, and pressed the Num Lock situation is reproduced.

Created attachment 599575
proof screenshot

Created attachment 599576
new backtrace with all debug symbols

Created attachment 599577
new backtrace with all debug symbols making minute later

udo: may be better report to upstream?

Created attachment 599614
backtrace for dconf-service

Mikhail, in comment 17 Tobias mentions an upstream bug that doesn't show progress yet.
So how do we improve from here?

This afternoon I found a blinking numlock LED again.
So comment 22's workaround did not help at all.
What is the progress?

Hi all,

this bug shows up for me as well.
FC17 x86_64 up to date.

dconf-service and gnome-settings-daemon are taking 100% CPU and doing a lot of I/O on disk.

For me it was triggered, _each time_, when using vino-server (Gnome 3 remote desktop) on the local machine (the one having the problem). I was connected from a distant client (this one did not malfunction ever) to this local machine.

I was killing both services to restore the usability of the remote machine, and it oftently crashes the session.
Eventually both services were automatically restarted and the problem was here again, and I had to kill both services again and risking a session crash.

Temporary fix :
Using dconf-editor : uncheck the check-box from org.gnome.settings-daemon.peripherals.keyboard.remember-numlock-state.
This temporary fix works for me.
(source: https://bugzilla.gnome.org/show_bug.cgi?id=679151)

Same problem on Ubuntu : https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/969359

Bye for now
Dag

Changed in gnome-settings-daemon (Ubuntu Precise):
milestone: ubuntu-12.04.1 → ubuntu-12.04.2
security vulnerability: no → yes
visibility: public → private
Tom Haddon (mthaddon) on 2012-08-07
visibility: private → public
William Grant (wgrant) on 2012-08-07
security vulnerability: yes → no

Created attachment 603269
new backtrace for gnome-settings-daemon

For me a workaround (!) was the disabling of 'remember numlock state' or whatever it was called.
The issue hasn't happened for a few days now since I did that.

(so yes I can confirm the Dag comment number 31)

FWIW: abrt choses my crashing g-s-d to be a dup of bug 716357.

Changed in gnome-settings-daemon:
status: New → Confirmed
Changed in gnome-settings-daemon:
status: Confirmed → Incomplete
description: updated
Changed in gnome-settings-daemon:
status: Incomplete → Confirmed

Created attachment 635290
gdb backtrace when g-s-d consumes 100% cpu

I've encountered the similar issue. g-s-d now consumes 100% cpu. gdb log attached.

Looks like 100% reproducible when pressing NumLock key twice.

Changed in gnome-settings-daemon:
status: Confirmed → In Progress
Changed in gnome-settings-daemon:
status: In Progress → Fix Released
Changed in gnome-settings-daemon (Ubuntu Quantal):
importance: Undecided → High
status: New → In Progress
Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Fix Committed
description: updated
description: updated
Changed in gnome-settings-daemon (Ubuntu):
status: Fix Committed → Fix Released
Steve Langasek (vorlon) on 2012-11-27
Changed in gnome-settings-daemon (Ubuntu Precise):
status: Triaged → Fix Committed
tags: added: verification-needed
tags: added: verification-done
removed: verification-needed
Changed in gnome-settings-daemon (Ubuntu Quantal):
status: In Progress → Fix Committed
tags: removed: verification-done
tags: added: verification-needed
tags: added: verification-done-precise
Changed in gnome-settings-daemon (Ubuntu Precise):
status: Fix Committed → Fix Released

Still an issue with 3.4.2 with currently stable F17. So a backport would be appreciated.

tags: added: verification-done-quantal
Colin Watson (cjwatson) on 2013-01-30
tags: removed: verification-needed
Changed in gnome-settings-daemon (Ubuntu Quantal):
status: Fix Committed → Fix Released

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in gnome-settings-daemon (Fedora):
importance: Unknown → Critical
status: Unknown → Won't Fix
Displaying first 40 and last 40 comments. View all 220 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.