• El problema. Los archivos borrados siguen ocupando espacio mientras un proceso en ejecución los tenga abiertos. Ni el Finder, ni el panel Almacenamiento, ni du los ven.
  • Lo que descubrimos. Un proceso en segundo plano llamado chronod retenía 174 copias borradas de una base de datos del sistema. Al reiniciarlo se recuperaron 2,03 GB en menos de tres segundos.
  • Lo que construimos. Mint 1.0.82 muestra estos archivos en Safe to clean y solo cuenta lo que debería recuperarse al finalizar un proceso en segundo plano de macOS. Mint nunca marca esa fila por ti.

Si borras archivos y el espacio libre de tu Mac no aumenta, puede que un proceso en ejecución todavía los tenga abiertos. macOS conserva los datos de un archivo borrado hasta que los libera el último proceso que lo retiene, y todo lo que cuenta por carpetas los pasa por alto, incluidos el Finder, el panel Almacenamiento y du. En uno de nuestros Mac, un proceso en segundo plano llamado chronod retenía 174 copias borradas de una base de datos del sistema. Al reiniciarlo se recuperaron 2,03 GB en menos de tres segundos.

La primera vez que lo medimos, tres días antes, llegamos a una conclusión equivocada. Es un error fácil de cometer en cualquier Mac, así que a continuación también contamos cómo ocurrió.

Borrar un archivo elimina su nombre

Cuando borras un archivo, macOS elimina su nombre de la carpeta. Si un proceso todavía tiene el archivo abierto, o mapeado en su memoria, los datos se quedan en el disco hasta que ese proceso lo libera. El espacio sigue contando como usado, pero ninguna carpeta lo contiene, así que cualquier herramienta que sume carpetas se queda corta.

lsof enumera estos archivos. Su opción +L1 lista los archivos abiertos que ya no tienen nombre. Este comando muestra cuánto retiene cada proceso, de mayor a menor:

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

Solo lee y no pide contraseña. Sin sudo delante, solo ve los procesos que se ejecutan con tu usuario, no los que se ejecutan como root. Los tamaños son longitudes de archivo, y un archivo que tienen abierto dos procesos se cuenta en los dos, así que finalizar un proceso puede devolver menos de lo que indica su línea. Lo explicamos más adelante.

Lo que retenía uno de nuestros Mac

A las 02:22 (hora del Pacífico) del 4 de octubre, casi cinco días después del último arranque, lsof listaba 324 archivos borrados que seguían abiertos, 2,88 GB por longitud. Un solo proceso retenía la mayor parte:

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

Todos los archivos de chronod menos uno eran copias antiguas de la base de datos de LaunchServices, la lista que macOS mantiene de las apps instaladas y de los archivos y enlaces que abre cada una. Cada copia ocupa unos 13 MB. chronod es el proceso del sistema que mantiene actualizados los widgets. Llevaba en ejecución desde las 15:50 del 2 de octubre: 34,5 horas.

Reiniciar chronod

launchd, que inicia los procesos en segundo plano de macOS, vuelve a iniciar chronod cuando algo lo necesita. Así que lo finalizamos y observamos el espacio libre:

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

El espacio libre aumentó 2,03 GB en 2,5 segundos y se mantuvo así. En menos de un minuto ya había un chronod nuevo en ejecución.

Los 2,03 GB son el 89 % de los 2,28 GB que listó lsof. El resto se explica porque algunos archivos estaban compartidos: 20 de las copias de chronod, 0,25 GB, también estaban abiertas en otros procesos, y esos bloques se quedan hasta que los libera el último que los retiene. 2,28 menos 0,25 son 2,03, la cifra que medimos. Así que las longitudes de lsof eran correctas, y un reinicio devuelve la longitud de los archivos que solo retiene ese proceso.

Nuestra primera medición estaba mal

Vimos por primera vez la acumulación de copias de chronod el 1 de octubre, mientras el índice de Spotlight se comía el espacio libre de ese mismo equipo (esa historia está aquí). chronod llevaba en ejecución desde el arranque del 29 de septiembre y retenía 827 copias borradas, 5,49 GB por longitud. Trece minutos después retenía 836.

Después, en el plazo de un minuto, pasaron tres cosas: desactivamos la indexación de Spotlight, borramos su índice y reiniciamos chronod. Las lecturas de espacio libre, en hora del Pacífico:

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

En nuestras notas de esa tarde atribuimos los 4 GiB a borrar el índice. Para evaluar chronod comparamos las lecturas de las 12:46:43 y las 12:46:57, y las dos eran posteriores a su reinicio, así que parecía que chronod no había devuelto casi nada. Escribimos que probablemente sus copias compartían bloques y que lsof exageraba el espacio.

La prueba del 4 de octubre, con un solo cambio y lecturas antes y después, dice lo contrario. Si chronod también devolvió alrededor del 89 % el 1 de octubre, sus 5,49 GB habrían sido unos 4,9 GB, y el salto de 4 GiB (4,3 GB, a partir de lecturas redondeadas a GiB enteros) encaja con eso. Ahora creemos que la mayor parte de ese salto fue cosa de chronod, y hemos corregido el artículo sobre Spotlight: desactivar el índice devolvió al menos 44 GiB, unos 47 GB, no los 51 GB que escribimos al principio.

Dos hábitos corrientes lo habrían detectado, y es fácil saltarse los dos: cambiar una sola cosa entre dos lecturas y comprobar la hora a la que se reinició un proceso (ps -o lstart= -p <pid>) en lugar de la hora a la que crees que lo reiniciaste.

Por qué chronod conserva copias antiguas

LaunchServices sustituye su base de datos escribiendo un archivo nuevo y borrando el antiguo. Un proceso que tiene mapeado el archivo antiguo lo conserva hasta que mapea el nuevo. chronod acumuló 827 copias en las 51 horas posteriores al arranque, unas 16 por hora, y 174 en sus siguientes 34,5 horas, unas 5 por hora. Los demás procesos que retenían copias acumularon muchas menos, así que parece algo propio de chronod, no de todo lo que lee esa base de datos.

Supusimos que lo provocaba compilar apps, ya que cada compilación registra una app nueva en LaunchServices y en nuestro Mac se compilan apps muchas veces al día. Una prueba rápida no lo aclaró: registrar una app y anular su registro tres veces en dos minutos añadió dos copias, y 30 segundos sin hacer nada añadieron una. Puede que las compilaciones aumenten el ritmo, pero no son lo único que lo desencadena. No sabemos por qué chronod deja que se acumulen copias antiguas.

Qué puedes hacer

  • Ejecuta la comprobación anterior. Si un proceso en segundo plano de macOS retiene más de lo que te gustaría, reinícialo, por ejemplo con killall chronod. launchd lo vuelve a iniciar. Desde el 1 de octubre hemos finalizado chronod tres veces en nuestro Mac, incluida la prueba anterior, sin que nada dejara de funcionar; los widgets se vuelven a dibujar.
  • Si los archivos los retiene una app, cierra la app. El 1 de octubre, Spotify retenía 281 archivos de caché borrados.
  • Reiniciar tu Mac lo libera todo.
  • No busques estos archivos en el Finder. Ya no les queda ningún nombre por el que encontrarlos.

Qué hace Mint

Mint 1.0.82 (del 2 de octubre) muestra en Safe to clean los archivos borrados que un proceso todavía retiene. Solo cuenta los archivos que no retiene ningún otro proceso, así que la cifra de la fila es lo que debería recuperarse al finalizar ese proceso. Solo lo ofrece para procesos en segundo plano de macOS que launchd vuelve a iniciar; los archivos que retiene una app van a Keep, con una nota para que cierres la app. Mint nunca marca esa fila por ti, y Auto Care nunca la ejecuta.

Preguntas

¿Dónde aparece este espacio en el panel Almacenamiento? No está en ninguna carpeta, así que no se puede asignar a una categoría. Suponemos que acaba en los Datos del sistema, la parte que el panel no puede desglosar, pero no lo hemos confirmado en el propio panel.

¿Es seguro finalizar chronod? launchd lo vuelve a iniciar en menos de un minuto. Lo hemos hecho tres veces en un solo Mac sin ningún problema que pudiéramos ver. Es una muestra pequeña, así que, si los widgets son importantes para tu trabajo, es mejor reiniciar tu Mac.

¿Volverá a pasar? Sí. chronod empezó a acumular copias de nuevo justo después de cada reinicio.