Description of problem: My journal is continuously spammed with messages such as: $ journalctl -f -- Logs begin at Sun 2014-06-01 03:10:01 CEST. -- Dec 01 11:53:29 localhost org.gnome.Shell.desktop[2211]: (gnome-shell:2211): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries Dec 01 11:53:29 localhost org.gnome.Shell.desktop[2211]: (gnome-shell:2211): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries Dec 01 11:53:29 localhost org.gnome.Shell.desktop[2211]: (gnome-shell:2211): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries Dec 01 11:53:29 localhost org.gnome.Shell.desktop[2211]: (gnome-shell:2211): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries Dec 01 11:53:29 localhost org.gnome.Shell.desktop[2211]: (gnome-shell:2211): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries ^C Would be nice to fix this. Version-Release number of selected component (if applicable): $ rpm -q gnome-shell gnome-shell-3.19.2-1.fc24.x86_64 $ rpm -q gtk3 gtk3-3.19.3-2.fc24.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Proposed as a Blocker for 24-final by Fedora user vondruch using the blocker tracking app because: Although gnome-shell is not exactly application, it is constantly spamming journal and hence increases disk and cpu load. "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." Link: https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Default_application_functionality
This does not meet that criterion even slightly. Log spew does not mean it fails basic functionality. -1 Blocker
"A bug in a Critical Path package that: * Cannot be fixed with a future stable update * Has a severity rating of high or greater and no reasonable workaround (see definition of severity and priority)" gnome-shell is a critical-path package, and while this could be fixed in the future, it not only makes the user journal large and useless, it consumes substantial cpu power doing so with no reasonable workaround
(In reply to Andrew Cook from comment #3) > "A bug in a Critical Path package that: > * Cannot be fixed with a future stable update This is the part that would qualify it as a blocker. Also, I don't know anyone who would consider log noise as having a severity rating of "high or greater".
It's the cpu usage more than journal spam, it's more than halved my battery life
This seems related to multi-monitor on my system (Dell XPS13 Intel Ivybridge Mobile). When the 2nd monitor is unplugged, gnome-shell is fine, but plug it in and I get this problem.
Any regressive behavior that cuts battery life in half is unsuitable for final release. If it's reproducible, widespread, with no work around, I'd say it violates "Bug hinders execution of required Alpha test plans or dramatically reduces test coverage" and make it alpha or beta blocking; I'd certainly curtail my testing given such behavior. It's just not worth dealing with. If it's happening only with 2+ displays attached, that sounds like a conditional blocker and perhaps comes down to a judgement call or votes at a later time. But I think it'd be unwise to ship a final release with 15% less battery life, let alone 50%. That's not a feature.
I retract my 2+ displays statement. Like the other testers on the upstream bug, it happens under other conditions also. Sorry for the noise and false debug path.
Discussed at 2016-02-15 blocker review meeting: [1]. We decided to punt the decision - this is a difficult judgement call and it's hard to make it with only a few (mostly QA) folks in attendance [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-15/f24-blocker-review.2016-02-15-17.00.html
Discussed at 2016-02-22 blocker review meeting: [1]. This bug was accepted as Final blocker: this is considered a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use", in that the Shell is the core of the "default panel" for Workstation and constantly spamming the system logs and consuming significant resources constitutes failing to "function correctly" [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-22/f24-blocker-review.2016-02-22-17.00.html
The upstream bug got closed, hopefully fixed. Now we need an update for Fedora.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
still happening
*** Bug 1314386 has been marked as a duplicate of this bug. ***
*** Bug 1309752 has been marked as a duplicate of this bug. ***
I've put workarounds for this in the gtk packages (gtk2 and gtk3)
(In reply to Matthias Clasen from comment #16) > I've put workarounds for this in the gtk packages (gtk2 and gtk3) Can I test them? What are the versions? Or are they in Fedora already, since the situation looks to be much better now: $ rpm -q gtk3 gtk3-3.19.11-1.fc25.x86_64 $ uptime 14:05:57 up 4:42, 1 user, load average: 0,68, 0,40, 0,34 $ journalctl -b | grep frame-clock | wc -l 18
the workaround is in 2.24.30 and will be in 3.19.12
should be fixed now. Please reopen if you still see it with post-alpha f24
Hi, I'd be happy to learn how I could avoid being affected by the same problem in my program (https://github.com/emilbarton/Unidatab). I've been looking for a solution on wxWidgets Discussion Forum (https://forums.wxwidgets.org/viewtopic.php?f=23&t=43009).
It happens on one of my system, when using filezilla. f25, mate, x86_64. Only 1 screen