Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I have none of these directories but still have A LOT of "Service exited due to SIGKILL | sent by mds" log entries in the system log... Every few minutes I get about 10-15 new entries.
Interesting. I wonder if the empty directories are in a slightly different place. If I substitute a 'T' for the 'C', I noticed one of my systems has 15,000 empty dirs in that place (a lot, but still far less than the 300,000 in the 'C' directory, though.

Try this command: ls /private/var/folders/*/*/T/com.apple.metadata.mdworker

Unfortunately, none of this tells us why the mds process is killing the mdworker.shared processes...
 
  • Like
Reactions: jagooch
I spent some time and reinstalled Big Sur from scratch on my 2018 Mac Mini and Late 2103 MacBook Pro. The problem occurs during the first login on the freshly installed OS, so it appears there is nothing to be done about it for now except disabling Spotlight. The problem will occur again as soon as it indexes the Time Machine drive since you cannot disable Spotlight for your TM backups.

Tiber
 
  • Like
Reactions: Brian33
Hey!

Since it seems that there is no way to disable indexing on time capsule… is there a way to encourage it? I mean, it seems that if you delete your backup, it's when this problem arise since there is no index of your backup and spotlight has to build it again, or at least it seems that is my case.

Is there a way to force the indexing? because it seems that now the problem is that the spotlight is only indexing the backup when the computer is backing up and most probably it's not enough time to build the index…
 
Hey…

I think I'm into something. In my case there is a volume that mounts on /Volumes/.timemachine/29CB9C93-2A70-454E-BFED-E020E4BB03DC/2021-03-17-143536.backup which I believe is the system snapshot of the last time I updated the system.

For some reason the mdworkers_shared are trying to index that and fail. I believe it's excluded from the spotlight index or perhaps it should be, but the exclusion is not working. I believe I saw something related to that volume one of the times I rebuild the spotlight index.
 
I think I'm into something. In my case there is a volume that mounts on /Volumes/.timemachine/29CB9C93-2A70-454E-BFED-E020E4BB03DC/2021-03-17-143536.backup which I believe is the system snapshot of the last time I updated the system.
That's interesting. It may be the source of the errors for you. I never see volumes like that mounted, but I know Time Machine works somewhat differently depending upon macOS version and the volume's filesystem format (I'm runnning Mojave). It seems to me that it wouldn't hurt for you to add that volume to your spotlight exclusions (System Preferences-->Spotlight-->Privacy).

I get the mdworker error messages in the system.log even when no backup is running and no odd filesystems mounted (verified with the 'mount' command), so something else is going on in my system!
 
  • Like
Reactions: jagooch
That's interesting. It may be the source of the errors for you. I never see volumes like that mounted, but I know Time Machine works somewhat differently depending upon macOS version and the volume's filesystem format (I'm runnning Mojave). It seems to me that it wouldn't hurt for you to add that volume to your spotlight exclusions (System Preferences-->Spotlight-->Privacy).

I get the mdworker error messages in the system.log even when no backup is running and no odd filesystems mounted (verified with the 'mount' command), so something else is going on in my system!
I can't add any of those volumes to the exclusion list. There is always an error.
 
  • Wow
Reactions: jagooch
I really don't know why those snapshots are open… I and why spotlight is —trying— to index them.
Screen Shot 2021-04-08 at 20.54.26.png
 
I don't have 3.5 billions of those folders but the number is nearing 100k.
I, too, have this annoying system.log spam problem with the SIGKILL messages – but I don't have GoogleDrive or some security camera monitoring app installed.

Question: What would happen if I deleted those 96391+511 folders? They (or others) will come back, right? So what exactly is Spotlight/mds/mdworker trying to index that makes these problems? How can I find out and then exclude those locations in Spotlights Privacy list? 😳

Screenshot 2021-04-10 at 22.38.15.png
 
What would happen if I deleted those 96391+511 folders?
On my Mojave and High Sierra systems, nothing happened, as far as I can tell. I deleted all but the last seven days worth of the folders in the 'C' directory. New ones are still created, but not at a very rapid pace.

So what exactly is Spotlight/mds/mdworker trying to index that makes these problems? How can I find out and then exclude those locations in Spotlights Privacy list?
I've tried (using 'lsof') to figure out what files the mdworker processes are accessing at or near the time of these errors, but I have not been successful. I've finally given up, deciding that it's not a big problem.

I've just freshly installed Big Sur 11.2.3 onto an external drive... and get the same system.log error messages. Looks like we'll have to live with them.
 
  • Like
Reactions: jagooch and lpuerto
I really don't know why those snapshots are open… I and why spotlight is —trying— to index them.
I don't know what those snapshots are, either. I think Spotlight will, by default, index every volume mounted in '/Volumes'. You might be able to turn off indexing for that particular volume by using the 'mdutil' command as follows...

If the volume is mounted at '/Volumes/.timemachine' (which is what your screenshot shows), then this command should give you it's current indexing status:

mdutil -s /Volumes/.timemachine

This command should turn off indexing for that volume:

mdutil -i off /Volumes/.timemachine
(Replace "off" with "on" to turn indexing on again.)

After the second command, re-issue the first command to verify the indexing is now off. Type 'man mdutil' to see the full documentation for the command.
 
I don't know what those snapshots are, either. I think Spotlight will, by default, index every volume mounted in '/Volumes'. You might be able to turn off indexing for that particular volume by using the 'mdutil' command as follows...

If the volume is mounted at '/Volumes/.timemachine' (which is what your screenshot shows), then this command should give you it's current indexing status:

mdutil -s /Volumes/.timemachine

This command should turn off indexing for that volume:

mdutil -i off /Volumes/.timemachine
(Replace "off" with "on" to turn indexing on again.)

After the second command, re-issue the first command to verify the indexing is now off. Type 'man mdutil' to see the full documentation for the command.
Bash:
$ mdutil -s /Volumes/.timemachine
/System/Volumes/Data/Volumes/.timemachine:
    Error: unknown indexing state.

Bash:
$ mdutil -i off /Volumes/.timemachine
/System/Volumes/Data/Volumes/.timemachine:
Error: invalid operation.
    Error: unknown indexing state.

dennis-nedry-gif-3.gif


Sorry but it isn't working —I tried before— and I even thing that those volumes are in principle excluded from Spotlight, but it isn't working.
 
  • Like
Reactions: jagooch
if you do:

Bash:
$ sudo mdutil -Ea
/:
    Indexing enabled.
/System/Volumes/Data:
    Indexing enabled.
/Volumes/.timemachine/TC Living Room._afpovertcp._tcp.local/1FA797B5-4B77-4AE2-99C1-47BE3617BDB2/O+L Backup:
2021-04-11 22:48:21.068 mdutil[75923:1296247] mdutil disabling Spotlight: /Volumes/.timemachine/TC Living Room._afpovertcp._tcp.local/1FA797B5-4B77-4AE2-99C1-47BE3617BDB2/O+L Backup -> kMDConfigSearchLevelOff
    Indexing and searching disabled.

and I believe I've seen /Volumes/.timemachine on that list.
 
I'm thinking that perhaps the issue has to do with the format of the back up? I mean on Big Sur the backups now can be APFS —or they are— and perhaps for that reason spotlight it's indexing them. I didn't have this problem before deleting my old backups and have new ones on APFS.

The thing is, is this a bug or a feature?
 
Bash:
$ mdutil -s /Volumes/.timemachine
/System/Volumes/Data/Volumes/.timemachine:
    Error: unknown indexing state.

Bash:
$ mdutil -i off /Volumes/.timemachine
/System/Volumes/Data/Volumes/.timemachine:
Error: invalid operation.
    Error: unknown indexing state.

dennis-nedry-gif-3.gif


Sorry but it isn't working —I tried before— and I even thing that those volumes are in principle excluded from Spotlight, but it isn't working.

@Brian33 I think my situation is similar to yours in that I don't have any odd volumes mounted or those orphaned dirs.

sh-3.2# ls -l /private/var/folders/*/*/C/com.apple.metadata.mdworker | wc -l
ls: /private/var/folders/*/*/C/com.apple.metadata.mdworker: No such file or directory
0


if you do:

Bash:
$ sudo mdutil -Ea
/:
    Indexing enabled.
/System/Volumes/Data:
    Indexing enabled.
/Volumes/.timemachine/TC Living Room._afpovertcp._tcp.local/1FA797B5-4B77-4AE2-99C1-47BE3617BDB2/O+L Backup:
2021-04-11 22:48:21.068 mdutil[75923:1296247] mdutil disabling Spotlight: /Volumes/.timemachine/TC Living Room._afpovertcp._tcp.local/1FA797B5-4B77-4AE2-99C1-47BE3617BDB2/O+L Backup -> kMDConfigSearchLevelOff
    Indexing and searching disabled.

and I believe I've seen /Volumes/.timemachine on that list.

Here is my output
sh-3.2# mdutil -Ea
/:
Indexing enabled.
/System/Volumes/Data:
Indexing enabled.
/Volumes/DATA:
2021-04-18 11:42:43.584 mdutil[53796:224046] mdutil disabling Spotlight: /Volumes/DATA -> kMDConfigSearchLevelOff
Indexing and searching disabled.


My Setup
2019 Macbook Pro 16" 32GB RAM 1TB SSD
Big Sur 11.2.3


Symptoms
Finder search returns the wrong results for files.
I get the mds related error messages every few seconds in /var/log/system.log.
tail -F /var/log/system.log
com.apple.xpc.launchd[1] (com.apple.mdworker.shared.0D000000-0700-0000-0000-000000000000[18816]): Service exited due to SIGKILL | sent by mds[98]
If I filter out the mdwork messages, I can see there is a memory allocation error ( root cause?) .
tail -F /var/log/system.log | grep -v com.apple.mdworker
mdworker_shared[88110]: mdworker_shared(88110,0x700000e3a000) malloc: malloc_memory_event_handler: approaching memory limit. Starting stack-logging.
mdworker_shared[88110]: mdworker_shared(88110,0x700000e3a000) malloc: recording malloc (and VM allocation) stacks using lite mode
mdworker_shared[88110]: mdworker_shared(88110,0x700000e3a000) malloc: malloc_memory_event_handler: stopping stack-logging
mdworker_shared[88110]: mdworker_shared(88110,0x700000e3a000) malloc: turning off recording malloc and VM allocation stacks using lite mode
mdworker_shared[88110]: mdworker_shared(88110,0x700000fc0000) malloc: MallocStackLogging: stack id is invalid. Turning off stack logging
mdworker_shared[88110]: mdworker_shared(88110,0x700000fc0000) malloc: malloc stack logging not enabled.


Troubleshooting
Run disk repair on all container in recovery mode ( cmd+r on startup ).
Rebuild Spotlight Index as per Apple support article https://support.apple.com/en-us/HT201716.
Disconnect network drives.


Comments
I originally discovered the issue when use the preview feature of the Hazel app. I'd search for a file that should match the criteria, but results would be grayed out since the files weren't actually where the index said they are. This is a pretty big deal for me since the document index is a big part of my knowledge management system(KMS). If I need to know some information, the information comes from either from my Joplin notes or electronic document library.

I haven't researched the memory allocation error yet. Hopefully when I do , it isn't a dead end.

Update: malloc error was a dead end. I rebuilt my indexes using mdutil and so far the indexes seem to be up to date, ie search results are valid. I'm still getting the SIGKILL errors in /var/log/system.log, but Spotlight seems to be functional.
 
Last edited:
  • Like
Reactions: lpuerto
@Brian33 I think my situation is similar to yours in that I don't have any odd volumes mounted or those orphaned dirs.






Here is my output



My Setup
2019 Macbook Pro 16" 32GB RAM 1TB SSD
Big Sur 11.2.3


Symptoms
Finder search returns the wrong results for files.
I get the mds related error messages every few seconds in /var/log/system.log.


If I filter out the mdwork messages, I can see there is a memory allocation error ( root cause?) .




Troubleshooting
Run disk repair on all container in recovery mode ( cmd+r on startup ).
Rebuild Spotlight Index as per Apple support article https://support.apple.com/en-us/HT201716.
Disconnect network drives.


Comments
I originally discovered the issue when use the preview feature of the Hazel app. I'd search for a file that should match the criteria, but results would be grayed out since the files weren't actually where the index said they are. This is a pretty big deal for me since the document index is a big part of my knowledge management system(KMS). If I need to know some information, the information comes from either from my Joplin notes or electronic document library.

I haven't researched the memory allocation error yet. Hopefully when I do , it isn't a dead end.
I don't know if you are replying to me or to @Brian33. Anyhow…

I have "those odd" volumes because I think it's the expected behavior of time machine. I don't know if exactly those, but I think that time machine loads the last backup so it can check the differences and link. However, I see three problems, at least on my computer.

- At least for a while it was always mounting the exact backup… instead of the last one. What for?
- Spotlight is trying to index those… I really don't know why and what for. I think it's doing it because it think they are part of the hard drive or something since they have the same filesystem or something like that.
- Even if there is no backup volume mounted… there are those Service exited due to SIGKILL | sent by mds[88] on the system log…
 
Been suffering from the same symptoms on Catalina. Managed to stop the SIGKILL message by unloading the LaunchDaemon and once all that drivel stopped (was running at around 5 messages a second) I noticed something else:


Apr 23 18:26:29 ***-iMac mds[6202]: objc[6202]: Class MDSObjectToken is implemented in both /System/Library/PrivateFrameworks/SpotlightServerKit.framework/Versions/A/SpotlightServerKit (0x7fff93249120) and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds (0x106d68510). One of the two will be used. Which one is undefined.
Apr 23 18:26:29 ***-iMac mds[6202]: objc[6202]: Class MDSToken is implemented in both /System/Library/PrivateFrameworks/SpotlightServerKit.framework/Versions/A/SpotlightServerKit (0x7fff932490d0) and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds (0x106d68ab0). One of the two will be used. Which one is undefined.
Apr 23 18:26:29 ***-iMac mds[6202]: objc[6202]: Class _MDSPathFilter is implemented in both /System/Library/PrivateFrameworks/SpotlightIndex.framework/Versions/A/SpotlightIndex (0x7fff9321fae8) and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds (0x106d69668). One of the two will be used. Which one is undefined.
Apr 23 18:26:29 ***-iMac mds[6202]: objc[6202]: Class MDSReadCopyUpdate is implemented in both /System/Library/PrivateFrameworks/SpotlightServerKit.framework/Versions/A/SpotlightServerKit (0x7fff93249170) and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds (0x106d69730). One of the two will be used. Which one is undefined.
Apr 23 18:26:29 ***-iMac mds[6202]: objc[6202]: Class MDSInternalToken is implemented in both /System/Library/PrivateFrameworks/SpotlightServerKit.framework/Versions/A/SpotlightServerKit (0x7fff93249080) and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds (0x106d6a770). One of the two will be used. Which one is undefined.
Apr 23 18:26:30 ***-iMac mdsync[6203]: objc[6203]: Class MDSPathFilter is implemented in both /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdsync. One of the two will be used. Which one is undefined.

Maybe this will help someone to find a solution??

I just had another look and nothing has been written to system.log for 6 minutes so at least I can use my mac again without it crashing, but still have to deal with this:


ls -l /private/var/folders/*/*/C/com.apple.metadata.mdworker | wc -l

1394584
 
Been suffering from the same symptoms on Catalina. Managed to stop the SIGKILL message by unloading the LaunchDaemon and once all that drivel stopped (was running at around 5 messages a second) I noticed something else:


Apr 23 18:26:29 ***-iMac mds[6202]: objc[6202]: Class MDSObjectToken is implemented in both /System/Library/PrivateFrameworks/SpotlightServerKit.framework/Versions/A/SpotlightServerKit (0x7fff93249120) and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds (0x106d68510). One of the two will be used. Which one is undefined.
I get a lot of those "Class xxxxx is implemented in both yyyyyy and zzzzz" messages, too. I get them for many non-MDS classes, so I never felt they were related to the mdworker errors, though. As far as I can tell, they aren't a problem (except for spamming the system.log file).
 
but still have to deal with this:
To get rid of some orphaned directories I used the 'find' command with the '-empty' predicate to ensure I didn't delete any non-empty folders and '-mdtime' to delete those older than 7 days. Refine the command without the '-delete' predicate until you are sure it does what you want, then add '-delete' to the end of the command to do the for-real delete.

I'll attach my script, but I don't take any responsibility if it messes up your system!

This script worked on my Mojave and High Sierra systems, should work for Catalina, but won't work for Big Sur (because the orphaned dirs don't exist or are somewhere else in Big Sur).

It determines the (hopefully) proper target directory, prompts you to proceed, and then deletes all empty dirs in the target directory that are older than 7 days.

EDIT: I want to restate that I don't know that deleting the orphan directories does any measureable good. It might be best to let sleeping dogs lie!

Code:
#!/bin/bash                                                                                                              

# Use this command to delete all empty dirs older than 7 days

DAYS=7
CDIR=`ls -d /private/var/folders/*/*/C/com.apple.metadata.mdworker`
echo "Working on $CDIR..."
echo "...this may take awhile..."
COUNT=`find $CDIR -empty -mtime +${DAYS} -ls | wc -l`
echo "===> This user has $COUNT empty directories older than $DAYS days there."

CMD="find $CDIR -empty -mtime +$DAYS -delete"
echo "...about to run this command:"
echo " $CMD"

echo
echo "===> REALLY DELETE all empty directories older than $DAYS days there?"
echo "(Answer 1 or 2)"

select ANS in "Yes" "No"; do
   case $ANS in
      Yes ) $CMD; echo "Done."; break;;
      No ) echo "OK, aborted."; exit;;
      * ) echo "OK, aborted."; exit;;
   esac
done
 
  • Like
Reactions: armoured
well, it's probably a working solution for spam in your logs. you have to create a com.apple.mds file in /etc/asl/ with the content:

Code:
? [= Sender com.apple.xpc.launchd] claim only
* ignore

then:

Code:
sudo killall -HUP syslogd

of course you must have SIP disabled to do this.

more infos:
https://www.manpagez.com/man/5/asl.conf/

 
well, it's probably a working solution for spam in your logs. you have to create a com.apple.mds file in /etc/asl/ with the content:

Code:
? [= Sender com.apple.xpc.launchd] claim only
* ignore

then:

Code:
sudo killall -HUP syslogd

of course you must have SIP disabled to do this.

more:

Code:
man asl.conf

external links are awaiting moderator feedback
 
well, it's probably a working solution for spam in your logs. you have to create a com.apple.mds file in /etc/asl/ with the content:

Hey, thanks! I like to tinker with macOS, but I’ve never played around with ASL configuration stuff before. It looks like your example would filter out all messages from launchd, but looking at the man page it seems I could expand the query to act on specific messages. Cool! When I get some free time I’ll decipher the man page more and give a try just for fun!
 
I am not aware of any source of detailed and useful information, and utilities about, all things ASL/syslog on macOS than eclecticlight. There are some really great log querying/reporting utilities that may help a lot, I'm still learning myself which is why I'm in this thread (my trashcan6,1 with a zpool sprays stuff like this:

Code:
May  8 18:41:44 DreamOn com.apple.xpc.launchd[1] (com.apple.mdworker.shared.01000000-0600-0000-0000-000000000000[16268]): Service exited due to SIGKILL | sent by mds[1182]
May  8 18:41:44 DreamOn com.apple.xpc.launchd[1] (com.apple.mdworker.shared.20000000-0300-0000-0000-000000000000[16272]): Service exited due to SIGKILL | sent by mds[1182]
May  8 18:41:45 DreamOn com.apple.xpc.launchd[1] (com.apple.mdworker.shared.09000000-0100-0000-0000-000000000000[16211]): Service exited due to SIGKILL | sent by mds[1182]

All their posts tagged `log` are at https://eclecticlight.co/tag/log/ (there's a log called `logs` too that isn't as helpful, looks like their best stuff is usually tagged log so start there imo.
 
I have none of these directories but still have A LOT of "Service exited due to SIGKILL | sent by mds" log entries in the system log... Every few minutes I get about 10-15 new entries.
I also get zero matches so I assume Apple fixed it or changed it.
Maybe they moved into .bundle because I get 3700 matches if I instead do:
Code:
ls -l /private/var/folders/*/*/C/com.apple.mdworker.bundle | wc -l
 
To get rid of some orphaned directories I used the 'find' command with the '-empty' predicate to ensure I didn't delete any non-empty folders and '-mdtime' to delete those older than 7 days. Refine the command without the '-delete' predicate until you are sure it does what you want, then add '-delete' to the end of the command to do the for-real delete.

Thank you for this. I don't know that it's done much good either - we shall see - but I had 500k plus.

What I'd really like to understand is what spotlight is accessing that is driving it quite so crazy. Nothing immediately comes to mind.

Interesting data point: after using this script to delete all those empty folders (fell to ~10k), the KILLSIG messages fell pretty dramatically - like from about 10-15 in just a couple of minutes to 3-4 in a couple of minutes, and more or less continuously. Now there seems to be a gap between these smaller batches of mdworker sigkills of about five minutes or so. And the speed with which the number of these folders is increasing seems much slower.

So I can't help but wonder if there's an issue with spotlight also tracking these folders - so they come up due to whatever underlying errors, but then when these empty folders exceeds some number, it starts choking.

Beyond my ability to know though.
 
  • Like
Reactions: Brian33
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.