Hide Forgot
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:
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).
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.
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.
Should be fixed in telepathy-mission-control-5.16.3-1.fc20