Bug 1045261

Summary:	/usr/libexec/mission-control-5 using 100% CPU time since I log in (for 6 hours.)
Product:	[Fedora] Fedora	Reporter:	Hin-Tak Leung <htl10>
Component:	telepathy-mission-control	Assignee:	Peter Robinson <pbrobinson>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	bdpepple, pbrobinson
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	telepathy-mission-control-5.16.3-1.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-09-28 23:24:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Hin-Tak Leung 2013-12-20 03:23:27 UTC

Description of problem:

I have been running a git fetch and a many-windows browser session, and wondering why my computer is busy, but instead of the stuff I expect, I see in top:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                       
 1477 gdm       20   0  383764    992    992 R 100.4  0.1 361:33.00 mission-control                              

And it seems to be 100% since I log in/boot up! i.e. 6 hours ago!

$ uptime
 03:19:21 up  6:17,  9 users,  load average: 3.23, 3.36, 3.48

Version-Release number of selected component (if applicable):
telepathy-mission-control-5.16.0-2.fc20.x86_64

How reproducible:
Well, this is the 2nd day after upgrade, so it is the first "productive" session after a few short sessions with reboots, etc.

Steps to Reproduce:
1. I have no idea - it seems to be just there.
2.
3.

Actual results:
It is using 100% CPU, doing god know what. Luckily it is a dual-core system...

Expected results:
Nothing should be that busy, and I don't even know what it does!

Additional info:

Comment 1 Hin-Tak Leung 2013-12-20 03:53:29 UTC

It is definitely a WTF moment - I just kill -9 the process. I don't use any IM at all, nor interested in that area. WTF it is busy doing for 6 hours?

Also, none of the documentation (man page, etc) tell you what is the correct way to shut it down. Hello, I don't even know what it is, and from the description, I am sure I don't need it nor want it running. Can any of the man page or the url says one sentence, what is the recommended way of killing it, rather than "kill -9"?

FWIW, this is a gnome classic session (plain gnome session just dies on this hardware).

Comment 2 Hin-Tak Leung 2013-12-23 01:29:00 UTC

Just reboot/log-out/in, and saw it happening again. Looked at simply removing the package. While rpm -q --whatrequires says none, rpm -e says empathy and a few other things needs the shared library. sigh.

Need to either disable it or removing it.

Comment 3 Hin-Tak Leung 2013-12-25 14:54:58 UTC

I have put in /etc/rc.d/rc.local, 

echo "" > /usr/share/dbus-1/services/org.freedesktop.Telepathy.AccountManager.service
echo "" > /usr/share/dbus-1/services/org.freedesktop.Telepathy.MissionControl5.service

to nuke the service files every time I reboot. This is from past experience that systemd services have a tendency of coming back after being disabled, etc.

Comment 4 Peter Robinson 2014-09-28 23:24:40 UTC

Should be fixed in telepathy-mission-control-5.16.3-1.fc20