CPU going crazy with MRT after the update.

I've been following the comments here, as this is one of the few places on the Internet where MRT 1.68 problems are being discussed. Much thanks to hoakley at https://eclecticlight.co/2020/10/19/apple-has-pushed-updates-to-xprotect-and-mrt-17/ and others who have contributed to several solutions that have worked for me. In building this guide, I've borrowed liberally from others posts. Thank you all.

My OS: El Capitan 10.11.6

My machine: MacPro5,1

Three approaches have been successful for me in stopping the rampant CPU use by MRT.app. One requires installing another utility (App Tamer), and the other two require some command line wizardry. I'll summarize each one below.

First Approach: APP TAMER

1. Download App Tamer from the St. Clair Software site:

www.stclairsoft.com/AppTamer/

2. Install and in App Tamer's interface find MRT and check the box to "Stop this app completely."

If this works for you, nothing else is needed. When Apple fixes the problem, you can simply uncheck the box and the new version of MRT can do it's job.

Second Approach: Replace MRT.app 1.68 with a previous version

1. Obtain an older version of MRT.app from Time Machine or another backup. (I used 1.67).

2. Restart while holding down Command-R to boot into macOS Recovery.

3. Start Terminal from the Utilities menu.

4. Disable SIP from the command line:

csrutil disable

5. Exit Terminal and open Disk Utility. Find your boot drive in the list and unlock and mount it if necessary.

6. Exit Disk Utility and return to the terminal.

6. Delete the old copy of MRT.app:

rm -fR /Volumes/YourBootDrive/System/Library/CoreServices/MRT.app

7. Copy old version of MRT.app to the system:

cp /path/to/old/version/MRT.app /Volumes/YourBootDrive/System/Library/CoreServices/MRT.app

8. Re-enable SIP:

csrutil enable

9. Restart

10. VERY IMPORTANT: without this step the OS will reinstall MRT with the current version within hours. Immediately after restarting to your normal desktop, if you use El Capitan open System Preferences > App Store and uncheck "Install system data files and security updates." In other Mac OS versions you may need to do this in the Software Update pane. (Put a sticky on your screen to remind you to re-enable this when Apple has resolved the problem.)

Third Approach: Disable MRT.app by removing executable permissions

1. Restart while holding down Command-R to boot into macOS Recovery.

2. Start Terminal from the Utilities menu.

3. Disable SIP from the command line:

csrutil disable

4. Exit Terminal and open Disk Utility. Find your boot drive in the list and unlock and mount it if necessary.

5. Exit Disk Utility and return to the terminal.

6. Remove executable permissions from MRT.app:

chmod -R -x /Volumes/YourBootDrive/System/Library/CoreServices/MRT.app

7. Re-enable SIP:

csrutil enable

8. Restart

9. VERY IMPORTANT: without this step the OS will reinstall MRT with the current version within hours. Immediately after restarting to your normal desktop, if you use El Capitan open System Preferences > App Store and uncheck "Install system data files and security updates." In other Mac OS versions you may need to do this in the Software Update pane. (Put a sticky on your screen to remind you to re-enable this when Apple has resolved the problem.)

===

Finally, if you are having issues with MRT.app 1.68, released in Mid October, 2020, please report the issue to Apple. Please go to https://feedbackassistant.apple.com and report the issue, if you are a developer, or https://www.apple.com/feedback/macos.html if you are not a developer.

The more reports they get about MRT using massive amounts of CPU the quicker it will get fixed.

Thank you.

I got same issue. MRT just keep up and down and my CPU like crazy.

Since I got no Time Machine backup to downgrade MRT 1.68 to 1.67, I tried rename MRT.app to MRT.app.bak

And it works! My CPU now is calm.

path:

/Library/Apple/System/Library/CoreServices/MRT.app

You may need to disable SIP so you can rename MRT.app.

This is not a final solution. Hope Apple could fix it ASAP.

I tried everything I've read everywhere and none worked. I just gave up and applied brute force:

• Reboot into recovery (cmd-r while booting)
• Open terminal (utilities menu)
• csrutil disable
• Reboot (apple menu)
• Rename MRT.app to MRT.app.bak (make sure it won't end up MRT.bak.app)
• Reboot
• Same procedure but csrutil enable
• FINISHED

Finally my computer isn't working overtime as a toaster anymore. So far MRT.app hasn't been regenerated. I'm on Mojave.

Things that didn't work, but which may have an effect on not regenerating MRT (doubt it though):

sudo launchctl stop com.apple.mrt
sudo launchctl remove com.apple.mrt

Removing: /System/Library/LaunchDaemons/com.apple.MRTd.plist
Removing: /System/Library/LaunchAgents/com.apple.MRTa.plist

Make non-executable: chmod -R -x+X /System/Library/CoreServices/MRT.app

None of this worked even with sip disabled. Only solution was to rename the darn file. Way to go, Apple.

Looks like the current version is now (10/30/20, 1325) v1.69.3.

Had the same crash loop. Not sure when it started, but I sure noticed it yesterday.

Renaming MRT.app to MRT.app.bak stopped it from running. (disabled SIP, then reenabled)

I then executed sudo softwareupdate --background. After just a couple of minutes, I checked softwareupdate --history and saw the new MRTConfigData.

So far, so good... (now I have to go through the csrutil disable/enable reboots so I can delete the MRT.app.bak version)

Thanks all for the hints and tips.

Safe Boot, (holding Shift key down at startup), does the problem occur in Safe Mode?

Safe mode attempts to repair Disks & clears lots of caches & loads safe Drivers, & prevents loading of 3rd party extensions, so if Safe Mode works try again in regular boot.

If that doesn't do it, we might find the problem with an etrecheck report.

EtreCheck is a FREE simple little diagnostic tool to display the important details of your system configuration and allow you to copy that information to the Clipboard. It is meant to be used with Apple Support Communities to help people help you with your Mac. It will not display any personal info.

https://www.etrecheck.com/

Pastebin is a good place to paste the whole report if you capture the URL while there…

https://pastebin.com/

Whew, they've changed pastebin & made it harder, but after pasting in, click Create new paste button, then Embed button, then copy the URL...

<script src="https://pastebin.com/embed_js/KuvnghqA"></script>

The important part is...

https://pastebin.com/embed_js/KuvnghqA

Workable but harder for me to work with...the Note tool on the bottom of this editor's toolbar, as shown in the image, to copy and paste the output from EtreCheck. In a Reply before you click post, look for this to add longer texts...

El Capitan. (Cannot update to any later OS version as imac from early 2009)

I disabled SIP, renamed MRT, then reenabled SIP. All cool.

since then MRT update reverted to 1.67 (25/10/20).

Haven’t seen the 1.69 update yet.

is it bad to leave MRT permanently renamed/disabled?

I have a Mac Pro (Late 2013) running macOS Sierra (10.12.6). I never go the 1.68 update so I didn't have any issues. However, yesterday I received the update to 1.69.3 and the computer started to use a few processes running MRT (each with multiple threads at 100%). After a few hours, the computer was totally unresponsive. I had to do a hard shutdown and restart the machine. After a while I noticed that ssh commands would take a long time to run, even simple ones like cd or ls. So I used top and, again, I saw MRT processes using all the CPU. I found this thread and I disable SIP, rename the MRT.app and disable the automatic updates. So far, so good. I just wanted to pointed out that MRTConfigData 1.69.3 is not good at all for me. I have also reported the issue, but I don't know if that's useful at all... Anyone else having still issues with this latest version?

My other way

Use cpulimit.

Install cpulimit with Homebrew, and execute the following shell script.

#!/bin/sh

while :
do
  # Get the PID from the process name as PID changes every time MRT is restarted
  PID=$(pgrep MRT)
  # null check PID
  if [ -n "$PID" ]
  then
    # limite cpu usage to 1%
    echo yourpassward | sudo -S cpulimit -p $PID -l 1
  fi
  #10 seconds sleep in case a loop occurs
  sleep 10
done

I'm not very familiar with shell scripts, so there could be a problem with this script. In that case, please suggest an improved script.

Also, to have this shell script run automatically when the Mac starts up, create .sh file for that shell script and [any_name].command file, and write the path to the .sh file in .command file.

Then add that .command file to your Login item.

It seems more systems than El Capitan have this issue. Perhaps Apple is ignoring it since El Capitan is end of life.

But macOS Catalina has the same problem since MRTconfigdata 1.68.

Please go to https://feedbackassistant.apple.com and report the issue, if you are a developer.

Or https://www.apple.com/feedback/macos.html if you are not a developer.

The more reports they get about MRT using 100% cpu the quicker it will get fixed.

I can confirm I received MRT 1.69.3 today, Oct 30, 2020, 1405 PDT.

My OS: El Capitan 10.11.6

My machine: MacPro5,1

I have seen no excessive CPU usage since the update was installed by Apple. This seems to be the definitive fix, at least for my rig. I hope the same for everyone who had this problem.

Thanks to all here who helped out with this bug!

The same with Catalina 10.15.7 and MRT 1.68. CPU hitting 100% and CrashReport appears frequently in top.

Also. lots of console errors:

ошибка 15:48:21.661355+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/dmd/ConfigurationEngine/Database-shm

ошибка 15:48:21.661397+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/dmd/Policies/Database

ошибка 15:48:21.661427+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/dmd/Policies/Database-wal

ошибка 15:48:21.661508+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/dmd/Policies/Database

ошибка 15:48:21.661602+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/dmd/Policies/Database-wal

ошибка 15:48:21.665994+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/com.apple.LaunchServices.dv/com.apple.LaunchServices.trustedsignatures-501.db

ошибка 15:48:21.667130+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/folders/_6/r5pq_2vj393dl69grtddknb00000gn/0/com.apple.lockoutagent

ошибка 15:48:21.684313+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db

ошибка 15:48:21.684360+0300 kernel Sandbox: MRT(5909) System Policy: deny(1) file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-wal

ошибка 15:48:37.891865+0300 MRT os_unix.c:43353: (2) open(/var/db/DetachedSignatures) - No such file or directory

ошибка 15:48:37.918745+0300 MRT cannot open file at line 43353 of [378230ae7f]

ошибка 15:48:37.919441+0300 MRT os_unix.c:43353: (2) open(/var/db/DetachedSignatures) - No such file or directory

ошибка 15:48:37.919265+0300 MRT cannot open file at line 43353 of [378230ae7f]

ошибка 15:48:37.921833+0300 MRT os_unix.c:43353: (2) open(/var/db/DetachedSignatures) - No such file or directory

ошибка 15:48:37.932357+0300 MRT cannot open file at line 43353 of [378230ae7f]

So this work around actually worked for two machines, both afflicted. One running High Sierra and the other running Big Sur.

A few hours later, however, the Big Sur machine generated a new MRT.app and started trying to run that (all whilst the renamed file also sat there).

So I deleted them both (now that SIP had been disabled, that was easy to do) and since then the machine has run happily and without a regenerated hyperactive MRT application.

That said, I fully expect the file to return when the OS notices that it is missing, so it remains a workaround until Apple fix it. What I would strongly recommend is that you don't waste time on general maintenance or shell scripts. A huge thanks to the people suggesting these ideas but this is on Apple and the least time we spend on it, surely the better?!

Forgot to add how I temporary solved it – I had to install APP TAMER app to disable MRT or slow it down. It’s probably a bad idea but I don’t have any other solution now. It’s paid however. I looked at App Police app but that doesn’t see system processes.

Apple push MRT.app 1.67 already yesterday. So everyone should check this if you un-check it before:

Go to System Preferences > Software Update and click the Advanced button. Select Install system data files and security updates.