Huge RTCReporting Logs and Dropbox
One of our Macs kept filling up its SSD even though there isn’t supposed to be anything more stored on it. Photos is set to optimize its storage, and Messages is set to only keep messages for a year. It should be pretty much in a steady state, but we kept getting alerts from Mail that it couldn’t launch because there wasn’t enough free space. It’s an M4 MacBook Air used mostly for Web stuff, but somehow it felt as slow as the Intel one it had replaced.
I deleted unused apps and offloaded photos. Restarting sometimes helped, so I thought maybe it was an issue with Time Machine snapshots not being reclaimed promptly, which has been an issue before. But what data would even be changing so much to create large snapshots?
The problem kept getting worse, so I broke out OmniDiskSweeper. It didn’t find anything unusual, except it showed that the totals for the main folders added up to about 90 GB less than was reportedly used on SSD. Disk Utility showed that there were no snapshots taking up space. There must be real files but not ones that the app could see.
I relaunched OmniDiskSweeper using sudo, and it found a huge amount of stuff hidden in the root account: /private/var/root.
I had thought that wasn’t really used except when running Terminal from macOS Recovery. But apparently various daemons store all kinds of stuff there now. The /private/var/root/Library/Logs folder alone was using 74 GB, and there were also several multi-GB cache folders.
The logs were almost entirely from RTCReporting, and I’m not the only one to run into this.
I deleted the files using OmniDiskSweeper, but that didn’t help. It turns out that by default it moves files to the trash, and I guess since it was running under sudo this meant the invisible trash folder for the root account. It’s better to hold down the Option key to Delete Immediately.
After deleting the files and restarting the Mac, the free space looked right at first but then steadily dropped. Pretty soon there were again 5 GB of RTCReporting logs with the Mac just sitting there. I started using sudo du -h -d 2 /private/var/root/ to track how the sizes were changing. Within a day it was back up to 27 GB.
Activity Monitor showed that rtcreportingd and fileproviderd were each using almost 100% CPU constantly. I immediately suspected Dropbox because it had been working poorly on this Mac for a year or so. It wouldn’t keep files offline and constantly seemed to be syncing even when files weren’t changing. Sure enough, turning off Dropbox stopped the CPU use and the ballooning log files.
This was our last Mac still using Dropbox, so it seemed time to migrate it to iCloud Drive. The syncing problems ended up not being limited to keeping files offline. It couldn’t even reliably download most of them from the cloud to move them out of the Dropbox folder, instead reporting I/O errors for most files. And the files that I did move to the Documents folder never synced that deletion up to the cloud. I ended up just downloading the whole folder from the Web interface. iCloud Drive uploaded everything quickly and then settled into a state of no CPU use.
Previously:
- Sunsetting Maestral
- When Dropbox Spawns a Million Folders
- Tahoe Free Space Problems
- Fixing “Optimize Storage”
- Update on Cloud File Provider Extensions
2 Comments RSS · Twitter · Mastodon
The irony of present-day Dropbox’s client being such a bloated upselling mess is that if I could just get the old client, I would happy pay for a Dropbox plan. But since I couldn’t, I just didn’t, and by the time Maestral appeared it was way too late.
I’m certain I don’t matter, because Slopbox just wants that enterprise money like every other rotted productivity app these days wants, but I’m also sure I’m not alone.
@Billyok Yes, and the other irony is that it worked so much better when it was a dirty hack vs. using the public file provider API.
