• The problem. Deleted files keep using space while a running process still has them open. Finder, the Storage pane and du all miss them.
  • What we found. A background process called chronod was holding 174 deleted copies of a system database. Restarting it gave back 2.03 GB in under three seconds.
  • What we built. Mint 1.0.82 lists these files in Safe to clean, counting only what ending a macOS background process should give back. The row is never ticked for you.

If you delete files and the free space on your Mac doesn't go up, a running process may still have them open. macOS keeps a deleted file's data until the last process holding it lets go, and anything that counts by folder misses it, including Finder, the Storage pane and du. On one of our Macs, a background process called chronod was holding 174 deleted copies of a system database. Restarting it gave back 2.03 GB in under three seconds.

When we first measured this, three days earlier, we got the answer wrong. The same mistake is easy to make on any Mac, so how it happened is below too.

Deleting a file removes its name

When you delete a file, macOS removes its name from the folder. If a process still has the file open, or mapped into its memory, the data stays on the disk until that process lets go. The space still counts as used, but no folder contains it, so any tool that adds up folders comes out short.

lsof lists these files. Its +L1 option shows open files with no name left. This prints how much each process is holding, largest first:

lsof +c 0 -nP +L1 |
  awk 'NR>1 && $5=="REG" && !seen[$9 FS $1]++ {s[$1]+=$7}
       END {for (p in s) if (s[p]>=1e7) printf "%8.2f GB  %s\n", s[p]/1e9, p}' |
  sort -rn

It only reads and needs no password. Without sudo in front it sees only processes running as you, not the ones running as root. The sizes are file lengths, and a file two processes hold open is counted under both, so ending one process can give back less than its line says. More on that below.

What one Mac was holding

At 02:22 Pacific time on October 4, nearly five days after the Mac last started up, lsof listed 324 deleted files still open, 2.88 GB by length. One process held most of it:

process                       deleted files    length
chronod                                 172   2.24 GB
linkd                                    17   0.21 GB
an Insta360 camera extension              2   0.07 GB
fileproviderd                             6   0.06 GB

All but one of chronod's files were old copies of the LaunchServices database, the list macOS keeps of the apps on the Mac and the files and links each one opens. Each copy is about 13 MB. chronod is the system process that keeps widgets up to date. It had been running since 15:50 on October 2, 34.5 hours.

Restarting chronod

launchd, which starts macOS's background processes, starts chronod again when something needs it. So we ended it and watched the free space:

02:26  chronod holds 174 deleted copies, 2.276 GB by length
       free space, 6 readings over 10 s:   39.834 to 39.879 GB
       SIGTERM to chronod
+2.5 s free space:                         41.910 GB
+30 s  free space, 12 readings:            41.899 to 41.912 GB

Free space went up by 2.03 GB within 2.5 seconds and stayed there. A new chronod was running within a minute.

2.03 GB is 89% of the 2.28 GB lsof listed. The rest is explained by sharing: 20 of chronod's copies, 0.25 GB, were also open in other processes, and those blocks stay until the last holder lets go. 2.28 minus 0.25 is 2.03, the figure we measured. So lsof's lengths were right, and a restart gives back the length of the files only that process holds.

Our first measurement was wrong

We first saw chronod's pile on October 1, while Spotlight's index was eating the same Mac's free space (that story is here). chronod had been running since the Mac started up on September 29 and held 827 deleted copies, 5.49 GB by length. Thirteen minutes later it held 836.

Then, within one minute, three things happened: we turned Spotlight indexing off, erased its index, and restarted chronod. The free-space readings, Pacific time:

12:46:22  57 GiB free   (after indexing was turned off)
12:46:40  new chronod starts
12:46:43  61 GiB free   (index erased, chronod restarted)
12:46:57  61 GiB free

In our notes that afternoon we credited the 4 GiB to erasing the index. To judge chronod we compared the readings at 12:46:43 and 12:46:57, and both came after its restart, so chronod seemed to have given back almost nothing. We wrote that its copies probably shared their blocks and that lsof overstated the space.

The October 4 test, one change with readings on both sides, says otherwise. If chronod gave back about 89% on October 1 as well, its 5.49 GB would have been about 4.9 GB, and the 4 GiB jump (4.3 GB, from readings rounded to whole GiB) fits that. Most of that jump, we now think, was chronod's, and we've corrected the Spotlight post: turning the index off gave back at least 44 GiB, about 47 GB, not the 51 GB we first wrote.

Two ordinary habits would have caught it, and both are easy to skip: change one thing between two readings, and check the time a process restarted (ps -o lstart= -p <pid>) instead of the time you think you restarted it.

Why chronod keeps old copies

LaunchServices replaces its database by writing a new file and deleting the old one. A process that has the old file mapped keeps it until it maps the new one. chronod kept 827 copies in the 51 hours after the Mac started up, about 16 an hour, and 174 in its next 34.5 hours, about 5 an hour. The other processes holding copies kept far fewer, so this looks like something about chronod, not about every reader of the database.

We guessed that building apps drives it, since each build registers a new app with LaunchServices and this Mac builds apps many times a day. A quick test didn't settle it: registering and unregistering an app three times in two minutes added two copies, and 30 seconds of doing nothing added one. Builds may raise the rate, but they aren't the only trigger. We don't know why chronod lets old copies pile up.

What you can do

  • Run the check above. If a macOS background process holds more than you'd like, restart it, for example killall chronod. launchd starts it again. We've ended chronod on this Mac three times since October 1, the test above included, and saw nothing break; widgets redraw.
  • If an app holds the files, quit the app. On October 1, Spotify held 281 deleted cache files.
  • Restarting the Mac lets go of everything.
  • Don't look for these files in Finder. They have no name left to find.

What Mint does

Mint 1.0.82 (October 2) lists deleted files a process still holds in Safe to clean. It counts only the files no other process holds, so the number on the row is what ending that process should give back. It offers this only for macOS background processes that launchd starts again; an app's held files go to Keep with a note to quit the app. The row is never ticked for you, and Auto Care never runs it.

Questions

Where does this space show up in the Storage pane? No folder holds it, so it can't be attributed to a category. We expect it ends up in System Data, the part the pane can't break down, but we haven't confirmed that against the pane itself.

Is it safe to end chronod? launchd starts it again within a minute. We've done it three times on one Mac with no problem we could see. That's a small sample, so if widgets matter to your work, restart the Mac instead.

Will it come back? Yes. chronod started piling up copies again right after each restart.