I just updated to to macOS Mojave version 10.14 Beta and I have noticed a new process called YaraScanService. The process is consuming too much RAM (around 10GB ). I killed the process using Activity Monitor but it came back an hour later.

  • What is this process and what it exactly do?
  • Is there a way to shut it down it and/or stop it from hogging memory?

MRT/YaraScan is a MacOS prodvided antivirus-copyright tool. The reason for its obscene memory usage is basically why OSX doesn't have a formal 'antivirus'.

More simply, YaraScan is one part of the 'volatility suite' here; https://www.volatilityfoundation.org/about

Please realise that a virus and illegally pirated material both are only detected by a 'signature' set of code paths and both often reliant on bugs, exploits and weak patching, so it's only to be expected that the strongest modern antivirus was grown from a copyright infringement detection tool.

YaraScan runs once after Mojave update, and then deletes itself. It has also been seen to persist on certain MacOS systems within MRT. The reason it uses so much memory is because unless otherwise programmed (as in it's an opt-out), a process that has to scan an large amount of files for an unknown sized file that might be encrypted into said searched files will use a large amount of inactive memory to save all decrypted scanned files for a limited amount of time incase they are needed again. Why? Because empty RAM is wasted RAM, I mean you still have to give it watts so why delete the stuff on it when something else doesn't want to be there? It takes 100x longer to get it back.

More importantly, if you Filevault or APFS, ALL of that data is encrypted and must be decrypted to be read. Many apps actually need launching and then scanning when they are loaded as many files can come together to form a threat in memory space as a single 'concurrent file'. Viruses can be partially stored in a dylib for a completely unrelated app.

The amount of time is actively decided by Grand Central Dispatch in your Mac and as soon as you attempt to use a program that needs that logical RAM it will try to clear it. Note that Virtual Memory in this case should be large, as all that decrypted stuff is better stored there until you're literally out of space than deleted on a secondary pass shortly after creation repeatedly.

This is new behavior in the age of SSDs to maximize drive life over responsiveness. Current GCD behavior suggests that the slowdowns are from a fast CPU creating decrypted data faster than it can be written to disk and other requests to RAM having to wait for SSD/HDD to finish.

  • 10
    So Apple is snooping on people's storage without their knowledge? How is this not front-page news a-la Sony DRM-gate? – dhchdhd Jul 19 '18 at 4:37
  • 4
    YaraScan runs once after Mojave update, and then deletes itself. It's running for me after a kernel panic, so I assume the system loads it from the recovery drive as needed. Just FYI. – undefined Aug 21 '18 at 20:27
  • 1
    Good to know this is a run-once deal. I just refreshed my OS after have a series of issues and then seeing an unfamiliar virus related program was troubling. – Dan Loughney Aug 30 '18 at 16:01
  • 7
    It definitely did not delete itself after running on my machine. At peak, activity monitor showed it using 80.50 GB of RAM (my box has 32 GB physical ram). I let it run until the process disappeared. The executable still exists at /System/Library/CoreServices/MRT.app/Contents/XPCServices/YaraScanService.xpc. This is on macOS 10.13.6. – pjv Sep 20 '18 at 11:49
  • 1
    YaraScan is now part of XProtect/MRT/Gatekeeper. MRT being literally Malware Removal Tool. Prior to 10.13 I believe it's in the installer, but I am on the same system and do not have it present. I will update this answer to reflect this. As for the large RAM usage, please bear in mind this is virtual memory, AKA a file on the disk of X size (with the bonus of that file always deleting on close). It will be much bigger than RAM due to the fact that MRT won't use much RAM to store decrypted bytes, just dump it onto the disk until you run out of space then worry about delete. – user1901982 Oct 26 '18 at 15:35

It's running on 10.13.6 (17G65) also.

1054  66.3  2.1 62395936 359328   ??  Us   11:48AM  10:39.14 /System/Library/CoreServices/MRT.app/Contents/XPCServices/YaraScanService.xpc/Contents/MacOS/YaraScanService

Looks likely https://github.com/virustotal/yara


  • 3
    Indeed. From what I can tell YaraScanService is only part of MRT, and at least in 10.13.6 MRT seems to run after every reboot. It may not always run the YaraScanService part of itself, but in my experience it does. – Greg A. Woods Aug 8 '18 at 23:28
  • 4
    Such a great way of increasing obsolescence of older macs… Me: "My Mac is slow because of Yara!" Apple: "So you want to have viruses? Better upgrade your mac" – w00t Aug 18 '18 at 8:53
  • 2
    I ended up removing it bc I never run untrusted code. Apple adding performance-impacting features without providing an easy way to disable them (eg plist setting managed by a new Security prefpane field) seems a bit uncool. – dhchdhd Aug 31 '18 at 11:56

It does not really consumes your RAM. It likely uses memory mapped I/O when reading those files, but that only means that file content is mapped to virtual memory space, it doesn't actually mean that physical memory is used. For actual usage you need to look at "Real memory size in Activity Monitor.

  • 1
    Actually it does use RAM (and also memory mapped I/O uses RAM too -- that's the whole idea!), causing already-used RAM to be compressed and/or pushed out to swap, thus further exacerbating the usability of the system while it runs – Greg A. Woods Aug 8 '18 at 23:18
  • That's not how memory mapped file I/O works. It just maps the file to memory address space, it doesn't actually allocate any memory for it. The address space on 64bit platforms is 2^64 large (in theory, depending on platform some bits may have special purpose), which is way beyond the capacity of physical memory. – Matt K. Aug 10 '18 at 6:16
  • 1
    Memory-mapped I/O most definitely does "allocate" physical memory -- and thus it causes memory "pressure", forcing the kernel to compress and/or page-out otherwise active memory still used for other purposes. You can't put something into memory if you don't have somewhere specific in real physical memory allocated to copy it to. Virtual memory address space is directly mapped to physical memory whenever a process accesses it in any way, even if that particular area is backed by secondary storage as in memory-mapped I/O. – Greg A. Woods Aug 10 '18 at 22:17
  • Of course memory mapped files are accessed through physical memory, but those blocks are treated like a cache and they are first to go under memory pressure. No sane operating system paging implementation would compress or swap active memory pages while keeping significant amount of mmaped pages. In this case the YaraScanService on my computer had over 20 gigabytes mapped but only used around 300MB of physical memory. Basically claiming that memory mapped file I/O causes memory pressure is same as claiming disk cache causes swapping and memory pressure. – Matt K. Aug 11 '18 at 23:17
  • 1
    Memory mapped I/O requires a lot more physical memory than the equivalent buffer cache, especially with some access patterns. If you look at the amount of memory pressure (in the graph in the Activity Monitor "Memory" tab), and the growth of compressed memory and/or swap usage while YaraScanService runs on any machine with a large and full filesystem and lots of other large processes running you will see that it causes a severe amount of disruption to the extent that it sometimes causes thrashing. Even when Chrome leaks memory and grows huge it isn't nearly such a pig as YSS. – Greg A. Woods Aug 12 '18 at 1:12

Having lived with 10.13.6 (as far as I could take my hw) and the nightmare of yarascanservice (using Automator to script a 'forced quit' of the service shortly after every start up), I also ran in to major issues being unable to install Security Updates (corrupting the OS - widely experienced, thanks Apple). I therefore had to avoid any aspect of auto-updating taking place, and may have over-tinkered with System Preferences.

System Preferences / App Store - among the various options that I had defeated, a badly worded option is:

'Install system data files and security updates'

I came across an article on tidbits explaining what function this option served, recommending to enable it (https://tidbits.com/2016/03/30/make-sure-youre-getting-os-x-security-data/).

It appears that this enables updates to MRT (which drives yarascanservice). Despite the clumsy naming used, this does not cause major security updates to the main OS to occur - simply low level updates (similar to updating definitions in a virus application).

I had this option disabled.

Enabling it, and forcing the system to run these updates, I confirmed that new data had been downloaded (see link above for directions).

Ever since (4 days ago), I haven't seen yarascanservice running.

This may be coincidence, but I'm curious to determine if this has resolved a similar issue for others?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.