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