Constant high CPU after Security Update today

sspooner wrote:

Ah, when I say "remove" I mean remove from the current running processes, not remove the the actual file from disk.

That's why. Killing a process that is always set to run will only stop it until the next reboot. From earlier in the thread:

Interz, no need to wait and suffer, the solution (for me) took less than 10 seconds. Take a read of the thread before your post, it's a two-step process.

Open Utilities/Terminal, run the command to unload the process:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mrt.plist

Open Finder, select the file and Move to Trash:

/System/Library/LaunchDaemons/com.apple.mrt.plist

Restart. Worked for me.

Greg

Message was edited by: WZZZ

Yes, the point I was trying to get across is that my disk is clean. No perms problems and a verify disk comes back clean, so the speculation of clobbered perms or files doesn't seem valid.

Has nothing to do with Permissions or Directory problems. It appears to be a bug that, for some reason, is catching a number of users.

Spooner's experience calls for a minor tweak to our 'fix' ...

Open Utilities/Terminal, run the command to unload the process:

• sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mrt.plist
• copy and paste that command, enter your password, wait about 10 seconds

Open Finder, select the file and Move to Trash:

• /System/Library/LaunchDaemons/com.apple.mrt.plist
• enter your password to complete the removal
• verify that com.apple.mrt is not in Trash (if so, delete it)

Restart.

It is imperative that com.apple.mrt.plist is unloaded, moved to Trash, and does not remain in Trash. Once completed, the process will no longer run on any Restart.

Editorial comment - this 'fix' only addresses the sympton and does not determine the cause. The 10.6.8 MRT affected my newer MacBook Pro (2.66 GHz, vintage 2010) but not my MacBook Pro (2.4 GHz, vintage 2008) so far. Both are running the same OS 10.6.8 and both are Intel Core 2 Duo.

We should keep this discussion open until Apple/the community determines the cause. The MRT CPU consumption on the newer MacBook Pro is unacceptable and, therefore, requires this 'fix'. In this case, the Apple MRT ultimately become the malware that needs to be removed - go figure.

Greg

chiming in, this issue did not affect a 2010 MBP nor a 2008 MBP. There has got to be some common 3rd party app or setup that is causing this issue..

Greg - Thanks for the fix!

Apple - This is the second time we've had to apply a fix to this problem. I rely on the battery of my powerbook to provide power for several hours, and this MRT bug cause both a great deal of heat and drained my laptop's battery quickly. Moreover, it was nontrivial to identify the culprit. I suspect many Apple users don't even know that they have this problem.

Jeff in Madison wrote:

Apple - This is the second time we've had to apply a fix to this problem. I rely on the battery of my powerbook to provide power for several hours, and this MRT bug cause both a great deal of heat and drained my laptop's battery quickly. Moreover, it was nontrivial to identify the culprit. I suspect many Apple users don't even know that they have this problem.

Unfortunately nothing you write here constitutes a request to Apple and chances are nobody from Apple will even read it. If you have AppleCare give them a call. If not drop a line to feedback@apple.com.

Same issue here. 2nd time applying Greg's "fix". I am getting the "exit code" 4" message everyone else is getting. I have run the permissions fix. There needs to be a way to tell what file is causing the problem, and a way to solve this. Reinstalling the operating system is not acceptable.

feedback@apple.com does not appear to be valid.

We should promote Greg and ryanmoffet1 to experts 🙂

Found this in the system log, just in case Apple does reads this and does looks for root causes; it strengthens my opinion that this is a security tool race condition.

7/7/11 6:51:35 PM com.apple.mrt.uiagent[33363] Mon Jul 4 18:51:35 XxxxYyyy.local MRTAgent[33363] <Warning>: 3891612: (connectAndCheck) Untrusted apps are not allowed to connect to or launch Window Server before login.
7/7/11 6:51:35 PM com.apple.mrt.uiagent[33363] Mon Jul 4 18:51:35 XxxxYyyy.local MRTAgent[33363] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
7/7/11 6:51:35 PM com.apple.mrt.uiagent[33363] _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

7/7/11 6:58:11 PM com.apple.launchd[1] (com.apple.mrt[385]) Exited with exit code: 4
7/7/11 6:56:34 PM com.apple.launchd[1] (com.apple.mrt[38]) Exited with exit code: 4
7/7/11 6:56:38 PM com.apple.launchd[1] (com.apple.mrt[355]) Exited with exit code: 4
....
7/7/11 6:58:11 PM com.apple.launchd[1] (com.apple.mrt) Throttling respawn: Will start in 7 seconds
7/7/11 6:58:21 PM com.apple.launchd[1] (com.apple.mrt[392]) Exited with exit code: 4
7/7/11 6:58:21 PM com.apple.launchd[1] (com.apple.mrt) Throttling respawn: Will start in 7 seconds
7/7/11 6:58:31 PM com.apple.launchd[1] (com.apple.mrt[393]) Exited with exit code: 4
7/7/11 6:58:31 PM com.apple.launchd[1] (com.apple.mrt) Throttling respawn: Will start in 7 seconds
7/7/11 6:58:42 PM com.apple.launchd[1] (com.apple.mrt[401]) Exited with exit code: 4

Of course something freshly downloaded is "untrusted", even if it is a malware removal tool and it was downloaded from apple.com;

If I have some time, I'll remove Sophos, then re-install 10.6.8 patch ad see what happens.

But I would prefer the developers "who test everything before release" would have done this.

Dirk

If it's a race condition, do you realize how hard those are to find in testing? You can test all you want but not find a race condition until a specific, sometimes non-repeatable, situation occurs.

Also, I would consider the fact that only people who are having trouble would be seeking help on this. Then there's the millions of other people who downloaded the update just fine.

Lastly, operating systems are big and complex things. Things do break from time to time, no matter who wrote the code.

Yes, these types of issues are complicated, but I would think some detail about which file can't be removed would be do-able and the next step in solving it. "Re-install your operating system from DVD" is not an acceptable "solution". Also my Fortue-500 company has a web page that describes how to remove the files that are causing the MRT high CPU usage issue. CNET had an article on it etc. So this is not just an isolated issue that a few fringe people have experienced. I would argue the other side that there are millions of other "silent" people who don't go on forums and message boards who are just going about their day with their CPU needle pegged by MRT.

I know of no one who makes a backup of the OS prior installing an update from Apple. Some of the pieces of advice found in this discussion do not seem very realistic. And spending so much time in Terminal trying to make sense of where the processor cycles evaporate reminds me so much of chasing an OS 9 virus infection.

In fact, for those of us who are affected, we are experiencing much of the same symptoms as a virus infection, with the same cure:

1. machines grinds to a halt
2. re-install OS to alleviate problem
3. If #2 fails, chase a wild goose with Terminal weaponry and forum hopping

So for the rest of us who are not Terminal gurus, there are utilities out there that will clear MRT with one click. Search the web for Apple MRT removal tool.

Isn't this a case of getting sick by mandatory vaccination?

sjsherratt wrote:

feedback@apple.com does not appear to be valid.

Use http://www.apple.com/feedback/macosx.html for feedback about OS X issues. That is a web page form, not an email address.

pepinlebref wrote:

I know of no one who makes a backup of the OS prior installing an update from Apple.

That does not mean it isn't good practice. Many experienced Mac users strongly recommend making a bootable backup of the entire startup drive prior to applying any OS update, typically using Carbon Copy Cloner or SuperDuper! to make the process as painless as possible.

The reason for this is simple: the OS performs the update on itself. Any pre-existing problem with the OS, including in rarely used processes like those used only when applying updates, is likely to interfere with the update, which in turn is likely to cause even more problems in the future, including with unrelated files. In a perfect world this would never happen. But in the real one, there are things beyond either the user's or Apple's control that can modify or damage the OS.

If this happens, you cannot rely on the already damaged OS to repair itself.

So like it or not, in the event you are unlucky enough to have this happen to you, your only practical alternatives are to reinstall & re-update the OS or to restore from a backup. If reinstalling the OS is unacceptable to you, then make the backup. You may never need it but if you do, you will be glad you did.