Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Spotlight mdworker.shared file flooding system log; removal stops search index from working properly?

OffWorld said:
Ok, I'm at my wit's end with Spotlight. As I said, this bug is getting worse with every update! What I posted before only lasted until I rebooted, then it started trying to reindex my Time Machine drive the next time I plugged it in.

It also seems in Big Sur 11.5.2 you CANNOT turn Spotlight off! I went into Recovery, turned off SIP, rebooted, ran the commands to supposedly disable Spotlight, the terminal even says its disabled, but it's NOT. And since either Mojave or Catalina you can no longer exclude your Time Machine drive from Spotlight because it uses mds in some capacity, which is probably why you can't turn it off if Time Machine is enabled. But if I can't turn it off and I can't exclude my Time Machine drive it keeps flooding my log file with "Service exited due to SIGKILL" until I unmount my Time Machine drive.

In other words Spotlight is a useless buggy POS software that now means I *also* can't use Time Machine because it (for some reason) *requires* Spotlight now. I'm going to have to abandon using BOTH built-in Apple programs in the hope that using third-party solutions for backup and search will prevent Spotlight from trying to index things and flooding my log file.

Apple really needs to stop releasing new major versions every year and concentrate on fixing all the bugs in the current release. Especially because this bug has persisted over multiple major releases for YEARS already. I can't believe nobody at Apple is aware of this problem, and if so why can't they seem to fix it?
Click to expand...
I updated to Monterey Beta last week and the issue has disappeared for me.
 
Wow, that is truly valuable information! Thank you so much, MrMacintosh. Knowing about this upgrade issue could certainly save a lot of people a lot of trouble.
 
Thanks iamaydo for letting us know that this appears to be solved in Monterey Beta. I am looking forward to the general release next week. I hope to put this issue to bed as it has been a long running problem for a number of us. I also am glad someone finally figured out a workaround for related upgrade hanging issue.

Tiber
 
Good news that Apple has final had to acknowledge the problem. What an extraordinary and unnecessary mess.

The above article overcomplicates things, though.

The easiest, and fastest, way to check your counts of these directories is with:
Code: 
ls -l ${TMPDIR/T\//}'C/com.apple.metadata.mdworker' | wc -l

To delete the directories use:
Code: 
rm -rf ${TMPDIR/T\//}'C/com.apple.metadata.mdworker'

I've been using aliases to these for months now.
 
  • Like
Reactions: Houpla and TillichtoIllich
auxbuss said:
The easiest, and fastest, way to check your counts of these directories is with:
Code: 
ls -l ${TMPDIR/T\//}'C/com.apple.metadata.mdworker' | wc -l
Click to expand...
Last Friday I made a clean Big Sur install. After a few days, the messages appeared, but the result to that command was 0 (zero). I could't identify the real cause, but I think it might be related to some iCloud services, as I was trying to disable as many of them as possible when it happened and some got started accidentally (com.apple.CloudDocs.MobileDocumentsFileProvider).

iamaydo said:
I'm not entirely sure, but system log is not full of mdworker process being killed every two seconds
Click to expand...
Today I've upgraded to Monterey. If you keep Activity Monitor open and search for mdw, you will see that mdworker_shared still launches and closes by itself under user or _spotlight, but it's not multiple instances of it under the same user and none are logged in the console. So, I'm not sure if Apple fixed the problem or just disabled logging for that process.
 
bogdanw said:
So, I'm not sure if Apple fixed the problem or just disabled logging for that process.
Click to expand...
Well, it's still a problem in Catalina, even after this week's updates. The endless creation of empty directories is still happening, as are the logs made utterly useless by thousands of messages.

I'm genuinely sad about this. Apple is now not fixing known problems in supported OSs. Well… clearly they aren't really supporting them, but just going through the political motions of pretending to. What a sad, sad state of affairs.
 
  • Like
Reactions: TillichtoIllich
It turns out, in Monterey, Apple moved the mdworker.shared messages from the system log to the launchd.log
By the look of it, it seems spawning and killing mdworker.shared processes is considered normal behaviour.
<Notice>: internal event: PETRIFIED :)
Code: 
2021-10-30 17:27:51.635813 (user/89/com.apple.mdworker.sizing) <Notice>: internal event: WILL_SPAWN, code = 0
2021-10-30 17:27:51.635835 (user/89/com.apple.mdworker.sizing) <Notice>: service state: spawn scheduled
2021-10-30 17:27:51.635837 (user/89/com.apple.mdworker.sizing) <Notice>: service state: spawning
2021-10-30 17:27:51.635898 (user/89/com.apple.mdworker.sizing) <Notice>: launching: ipc (mach)
2021-10-30 17:27:51.637260 (user/89/com.apple.mdworker.sizing [539]) <Notice>: xpcproxy spawned with pid 539
2021-10-30 17:27:51.637276 (user/89/com.apple.mdworker.sizing [539]) <Notice>: internal event: SPAWNED, code = 0
2021-10-30 17:27:51.637279 (user/89/com.apple.mdworker.sizing [539]) <Notice>: service state: xpcproxy
2021-10-30 17:27:51.637288 (user/89/com.apple.mdworker.sizing [539]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2021-10-30 17:27:51.643930 (user/89/com.apple.mdworker.sizing [539]) <Notice>: service state: running
2021-10-30 17:27:51.643940 (user/89/com.apple.mdworker.sizing [539]) <Notice>: internal event: INIT, code = 0
2021-10-30 17:27:51.643945 (user/89/com.apple.mdworker.sizing [539]) <Notice>: Successfully spawned mdworker[539] because ipc (mach)
2021-10-30 17:27:52.395780 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: service exited: dirty = 0, supported pressured-exit = 1
2021-10-30 17:27:52.395790 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: Service exited due to SIGKILL | sent by mds[88]
2021-10-30 17:27:52.395792 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: exited due to SIGKILL | sent by mds[88]
2021-10-30 17:27:52.395794 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: service state: exited
2021-10-30 17:27:52.395797 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: internal event: EXITED, code = 0
2021-10-30 17:27:52.395798 (user/501) <Notice>: service inactive: com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000
2021-10-30 17:27:52.395800 (user/501) <Notice>: removing service: com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000
2021-10-30 17:27:52.395845 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: internal event: PETRIFIED, code = 0
2021-10-30 17:27:52.395847 (user/501/com.apple.mdworker.shared.06000000-0000-0000-0000-000000000000 [526]) <Notice>: service state: not running
2021-10-30 17:27:52.399449 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: service exited: dirty = 0, supported pressured-exit = 1
2021-10-30 17:27:52.399459 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: Service exited due to SIGKILL | sent by mds[88]
2021-10-30 17:27:52.399461 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: exited due to SIGKILL | sent by mds[88]
2021-10-30 17:27:52.399463 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: service state: exited
2021-10-30 17:27:52.399465 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: internal event: EXITED, code = 0
2021-10-30 17:27:52.399467 (user/501) <Notice>: service inactive: com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000
2021-10-30 17:27:52.399468 (user/501) <Notice>: removing service: com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000
2021-10-30 17:27:52.399512 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: internal event: PETRIFIED, code = 0
2021-10-30 17:27:52.399514 (user/501/com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000 [524]) <Notice>: service state: not running
2021-10-30 17:27:52.400415 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: service exited: dirty = 0, supported pressured-exit = 1
2021-10-30 17:27:52.400424 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: Service exited due to SIGKILL | sent by mds[88]
2021-10-30 17:27:52.400425 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: exited due to SIGKILL | sent by mds[88]
2021-10-30 17:27:52.400427 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: service state: exited
2021-10-30 17:27:52.400430 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: internal event: EXITED, code = 0
2021-10-30 17:27:52.400431 (user/501) <Notice>: service inactive: com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000
2021-10-30 17:27:52.400433 (user/501) <Notice>: removing service: com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000
2021-10-30 17:27:52.400463 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: internal event: PETRIFIED, code = 0
2021-10-30 17:27:52.400465 (user/501/com.apple.mdworker.shared.05000000-0000-0000-0000-000000000000 [523]) <Notice>: service state: not running
2021-10-30 17:27:52.910163 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000) <Notice>: internal event: WILL_SPAWN, code = 0
2021-10-30 17:27:52.910174 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000) <Notice>: service state: spawn scheduled
2021-10-30 17:27:52.910176 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000) <Notice>: service state: spawning
2021-10-30 17:27:52.910237 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000) <Notice>: launching: ipc (mach)
2021-10-30 17:27:52.911534 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: xpcproxy spawned with pid 540
2021-10-30 17:27:52.911549 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: internal event: SPAWNED, code = 0
2021-10-30 17:27:52.911552 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: service state: xpcproxy
2021-10-30 17:27:52.911561 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2021-10-30 17:27:52.911565 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000) <Notice>: internal event: WILL_SPAWN, code = 0
2021-10-30 17:27:52.911569 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000) <Notice>: service state: spawn scheduled
2021-10-30 17:27:52.911570 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000) <Notice>: service state: spawning
2021-10-30 17:27:52.911619 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000) <Notice>: launching: ipc (mach)
2021-10-30 17:27:52.912524 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: xpcproxy spawned with pid 541
2021-10-30 17:27:52.912538 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: internal event: SPAWNED, code = 0
2021-10-30 17:27:52.912541 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: service state: xpcproxy
2021-10-30 17:27:52.912559 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000) <Notice>: internal event: WILL_SPAWN, code = 0
2021-10-30 17:27:52.912562 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000) <Notice>: service state: spawn scheduled
2021-10-30 17:27:52.912563 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000) <Notice>: service state: spawning
2021-10-30 17:27:52.912614 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000) <Notice>: launching: ipc (mach)
2021-10-30 17:27:52.913492 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: xpcproxy spawned with pid 542
2021-10-30 17:27:52.913506 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: internal event: SPAWNED, code = 0
2021-10-30 17:27:52.913509 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: service state: xpcproxy
2021-10-30 17:27:52.913516 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2021-10-30 17:27:52.913562 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2021-10-30 17:27:52.916499 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: service state: running
2021-10-30 17:27:52.916508 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: internal event: INIT, code = 0
2021-10-30 17:27:52.916513 (user/501/com.apple.mdworker.shared.05000000-0100-0000-0000-000000000000 [541]) <Notice>: Successfully spawned mdworker_shared[541] because ipc (mach)
2021-10-30 17:27:52.916522 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: service state: running
2021-10-30 17:27:52.916524 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: internal event: INIT, code = 0
2021-10-30 17:27:52.916527 (user/501/com.apple.mdworker.shared.06000000-0100-0000-0000-000000000000 [540]) <Notice>: Successfully spawned mdworker_shared[540] because ipc (mach)
2021-10-30 17:27:52.917521 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: service state: running
2021-10-30 17:27:52.917524 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: internal event: INIT, code = 0
2021-10-30 17:27:52.917528 (user/501/com.apple.mdworker.shared.03000000-0100-0000-0000-000000000000 [542]) <Notice>: Successfully spawned mdworker_shared[542] because ipc (mach)
2021-10-30 17:27:54.873425 (system/com.apple.metadata.mds.scan [520]) <Notice>: service exited: dirty = 0, supported pressured-exit = 0
2021-10-30 17:27:54.873435 (system/com.apple.metadata.mds.scan [520]) <Notice>: exited due to exit(0)
2021-10-30 17:27:54.873437 (system/com.apple.metadata.mds.scan [520]) <Notice>: service state: exited
2021-10-30 17:27:54.873439 (system/com.apple.metadata.mds.scan [520]) <Notice>: internal event: EXITED, code = 0
2021-10-30 17:27:54.873442 (system) <Notice>: service inactive: com.apple.metadata.mds.scan
 
  • Like
Reactions: Brian33
Hi all.

The only way I have to see the empty files is using a "find" from "sudo". Using the "ls -l" command fail:

Code: 
$ ls -l ${TMPDIR/T\//}'C/com.apple.metadata.mdworker' | wc -l
ls: /var/folders/g9/rtdq080d08s48ldsd6l6yb_w0000gn/C/com.apple.metadata.mdworker: No such file or directory
       0

But using the "find".

Code: 
$ sudo find /private/var/folders/ -empty | grep com.apple.metadata.mdworker | wc -l
...
   48290

I see that the files are similar that you have all with 0 size.

Code: 
...
/private/var/folders//xc/5f1ghw113mj7g_nrbhvmcxkh0000gr/C/com.apple.metadata.mdworker//30328.82008
/private/var/folders//xc/5f1ghw113mj7g_nrbhvmcxkh0000gr/C/com.apple.metadata.mdworker//81672.221038
/private/var/folders//xc/5f1ghw113mj7g_nrbhvmcxkh0000gr/C/com.apple.metadata.mdworker//6927.17931
/private/var/folders//xc/5f1ghw113mj7g_nrbhvmcxkh0000gr/C/com.apple.metadata.mdworker//20497.325508
/private/var/folders//xc/5f1ghw113mj7g_nrbhvmcxkh0000gr/C/com.apple.metadata.mdworker//19644.45084
...

So the only way I have to remove the files is redirecting the output to a file, and doing some scripting:

Code: 
$ sudo find /private/var/folders/ -empty | grep com.apple.metadata.mdworker > pp

And the execute some scripts like these to find files older than Xdays.

Code: 
$ DAYS=7;for i in `cat pp | cut -f1,2,3,4,5,6,7,8 -d"/" | sort -u`; do echo $i;sudo find ${i} -empty -mtime +${DAYS} ; done | wc -l
   48294

And if I want to delete old files (more than 7 days)

Code: 
$ DAYS=7;for i in `cat pp | cut -f1,2,3,4,5,6,7,8 -d"/" | sort -u`; do echo $i;sudo find ${i} -empty -mtime +${DAYS} -delete; done | wc -l
   4

BYe...
 
The zero from the first commad is because it's only searching in one firectory. You need both:
Code: 
ls -l ${TMPDIR/T\//}'C/com.apple.metadata.mdworker' | wc -l
ls -l $TMPDIR'com.apple.metadata.mdworker' | wc -l

This is just the sum of the above two counts.
Code: 
sudo find /private/var/folders/ -empty | grep com.apple.metadata.mdworker | wc -l

You can clear both with:
Code: 
rm -rf ${TMPDIR/T\//}'C/com.apple.metadata.mdworker'
rm -rf ${TMPDIR}'com.apple.metadata.mdworker'

No sudo required. Their age is immaterial.
 
  • Like
Reactions: TillichtoIllich
Upgrading to Big Sur on one computer that had this issue in spades has made the accumulation of these directories drop to zero. Really, zero.
I still see mdworker being killed in console, but seems fewer and much quicker to do them.
That said, there are some beachballs on this system from time to time that I'm still trying to uproot.
 
auxbuss said:
The zero from the first commad is because it's only searching in one firectory. You need both:
Code: 
ls -l ${TMPDIR/T\//}'C/com.apple.metadata.mdworker' | wc -l
ls -l $TMPDIR'com.apple.metadata.mdworker' | wc -l

This is just the sum of the above two counts.
Code: 
sudo find /private/var/folders/ -empty | grep com.apple.metadata.mdworker | wc -l

You can clear both with:
Code: 
rm -rf ${TMPDIR/T\//}'C/com.apple.metadata.mdworker'
rm -rf ${TMPDIR}'com.apple.metadata.mdworker'

No sudo required. Their age is immaterial.
Click to expand...
Thanks for the instructions, auxbuss. One question.
My non-fresh install of Monterey 12.1, which is still running painfully slowly, tells me "no such file or directory" when I run those commands for com.apple.metadata.mdworker. When I run the command "mdfind mdworker" it returns the following list of 13, but, when I run your first two commands on them, they then also return "no such file or directory." Supposing that I could get the "clear" command to work, however, would it still be a good idea to do so without having seen any of the counts beforehand? Thanks again.


/usr/share/sandbox/mdworker.sb
/usr/share/sandbox/mdworker-sizing.sb
/usr/share/sandbox/mdworker-scan.sb
/usr/share/sandbox/mdworker-mail.sb
/usr/share/sandbox/mdworker-bundle.sb
/usr/share/man/man8/mdworker.8
/System/Library/LaunchAgents/com.apple.mdworker.shared.plist
/System/Library/LaunchAgents/com.apple.mdworker.sizing.plist
/System/Library/LaunchAgents/com.apple.mdworker.single.x86_64.plist
/System/Library/LaunchAgents/com.apple.mdworker.single.arm64.plist
/System/Library/LaunchAgents/com.apple.mdworker.mail.plist
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker_shared
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker
 
This may have stopped happening on the prior point update. But so far I don't see these files nor MDS SIGKILL messages in /var/log/system.log anymore since 12.4 update.
 
So the OP for this thread noted that people were able to make it stop by moving /System/Library/LaunchAgents/com.apple.mdworker.shared.plist but that might or does make Spotlight stop working and you have to have SIP disabled to mess with that file. So I wondered what would happen if, instead, I just copied it to /Library/LaunchAgents?

Here's what the Console shows:

Code: 
May 31 22:14:43 Mac-Mini-M1 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): Attempt to re-bootstrap service from different path, will use existing: service = com.apple.mdworker.shared, existing = /System/Library/LaunchAgents/com.apple.mdworker.shared.plist, conflicting = /Library/LaunchAgents/com.apple.mdworker.shared.plist
May 31 22:14:43 Mac-Mini-M1 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): Caller tried to import service with same label as an existing service: path = /Library/LaunchAgents/com.apple.mdworker.shared.plist, caller = mds.100
May 31 22:14:43 Mac-Mini-M1 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): exiting bootstrap mode
May 31 22:14:44 Mac-Mini-M1 com.apple.xpc.launchd[1] (com.apple.mdworker.shared.0A000000-0000-0000-0000-000000000000[6085]): Service exited due to SIGKILL | sent by mds[100]
...(and on and on and on and on)

So it seems it attempts to re-bootstrap the service from the new path, but sees it as conflicting, and then says it will use the "existing service" in the original location. The plist file contains a line with its own path so I edited the one I copied to reflect its new location.

I'm now curious if that conflicting message would go away if I moved the original so the only one the bootstrap service could find was in /Library/LaunchAgents/ and what - if any - effect that might have on this log-flooding problem. I don't have SIP turned off and don't really have time to keep playing with this. Maybe I'm barking up the wrong tree, I don't know.
 
Ok, so I gave up on trying to either move/remove /System/Library/LaunchAgents/com.apple.mdworker.plist or put an alternative one in /Library.

Even if I disable SIP the System volume is read-only so I can't move or remove it. I can put a copy in /Library and, as noted in my previous post, launchd does find it and try to bootstrap it but then rejects it in favor of the existing one in /System/Library.

If I tried to use launchctl to load the file in /Library it gives me: "ERROR: Path had bad ownership/permissions." So I did a chown to root:wheel on it which stopped that error but the "re-bootstrap" message remains the same, it still chooses the "existing" one in /System/Library.

I just wish Apple would FIX this stupid bug, but they apparently can't be bothered as it has persisted over multiple major versions of macOS now.

I can't have Spotlight enabled at all or it writes a SIGKILL line to my log file literally one per second. Given WRITES are what wear out an SSD this behavior is unacceptable. It's needlessly shortening the life of my non-replaceable storage. So Spotlight has to stay disabled, meaning I can't search for ANYTHING on my computer. Regardless, it will start doing it again if I mount my Time Machine drive. So I can't have THAT connected all the time either, which kind of defeats the entire purpose of it.

So the solutions to this problem would appear to be:

A. Switch to third-party solutions for backup and system search, though I'd also need to make sure the third-party search utility doesn't rely on Spotlight's index file (I believe Alfred does, so that's out).

B. Disable Spotlight's logging so it at least isn't needlessly writing to the SSD every second, but I'm not sure how to do that in either Big Sur or Monterey or if it's even possible with the read-only system volume.

C. Hope they FINALLY fixed this in Ventura? If someone who is beta testing it could see if they did. Of course they simply tried to hide it in Monterey by changing which log file it's flooding so I don't have high hopes they've fixed it.
 
at MBP 2015
macOS Catalina 10.15.7
it helped only unchecking all the checkboxes in spootlight and adding the entire disk to the exceptions ..
p.s. the problem started when the number of empty directories reached 190,000..

на MBP 2015 mid
macOS Catalina 10.15.7
помогло только снятие всех галочек в spootlight и добавление в исключения всего диска..
p.s. проблемы началась при достижении количества пустых каталогов в 190 000..
 
Resurrecting this old thread, I think this is still an issue in Ventura. Have those of you who posted on this thread found the same?
 
I used the ULBow utility to analyze the logs file, and in the last 30 minutes, mdworker had 468,000 entries - the total list of entries in that time was 485,000. (note: console does NOT show all the entries in the log file; it will have millions of entries potentially in a 24 or 48 hour day which do not show up in console). This is consistent behavior throughout the day. My system runs fine otherwise, I guess most people don't know about this which is why it doesn't get fixed. I filed a Feedback Assistant report on it, whether that will help or not...
 
donawalt said:
Resurrecting this old thread, I think this is still an issue in Ventura. Have those of you who posted on this thread found the same?
Click to expand...
I'm running Monterey 12.6.3 and it doesn't seem to be a problem for me; I used the following 'log show' command and got only 5 for the last 30 minutes, and only 135 for the last 24 hours:

Code: 
log show --info --last 30m --predicate 'sender == "launchd" &&  eventMessage contains[cd] "exited due to SIGKILL" '


donawalt said:
I used the ULBow utility to analyze the logs file, and in the last 30 minutes, mdworker had 468,000 entries - the total list of entries in that time was 485,000.
Click to expand...
Well, that is a lot! I am curious what predicate or filter you used in Ulbow.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back