Mientras investigaba un disco con un espacio libre cada vez menor y una CPU vinculada a >100 %, finalmente determiné que el problema era una mdworker
falla de segmento repetidamente, lo que mantenía muy ocupados a syslogd y CrashReporter.
Intenté reconstruir los índices de Spotlight de la manera habitual: primero, a través de la pestaña Privacidad en Preferencias del sistema -> Spotlight, luego a través de , mdworker -i off / ; mdworker -E -i on /
y lo mismo nuevamente pero con una intervención rm -rf /.Spotlight-V100
y un reinicio por si acaso; nada parecía resolver el problema.
Usando la pestaña Privacidad para excluir casi todo excepto /Applications/
, y luego agregando/eliminando esta carpeta para forzar un nuevo escaneo, y pude determinar que algunos archivos se indexan correctamente (y aparecen en los resultados de Spotlight) pero algunos no son ; hurgando un poco más opensnoop -n mdworker
revela que cuando mdworker
se inicia con UID 501, para escanear archivos de aplicaciones de mi propiedad funciona bien (y lo mismo para algunos otros UID que poseen archivos en /Applications/
), pero cuando se inicia con UID 89 ( _spotlight
, según a dscl . -list /Users UniqueID
) - presumiblemente para escanear archivos propiedad de root - segfaults.
Aquí hay una entrada de ejemplo de la Consola:
2015-07-16 13:53:25 com.apple.launchd[1] (0x100101670.mach_init.mdworker[13276]) Job appears to have crashed: Segmentation fault
2015-07-16 13:53:25 com.apple.ReportCrash.Root[13274] 2015-07-16 13:53:25.326 ReportCrash[13274:341b] Saved crash report for mdworker[13276] version ??? (???) to /Library/Logs/DiagnosticReports/mdworker_2015-07-16-135325-1_localhost.crash
Y aquí hay un extracto del informe del fallo (todos son prácticamente idénticos):
Process: mdworker [13276]
Path: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker
Identifier: mdworker
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Date/Time: 2015-07-16 13:53:25.085 +0100
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000010f5d1062
Crashed Thread: 3
[...]
Thread 3 Crashed:
0 ...ple.CoreServices.CarbonCore 0x00007fff867e7f0b CSStoreGetUnit + 84
1 com.apple.LaunchServices 0x00007fff821721ab _LSContainerCheckState + 65
2 com.apple.LaunchServices 0x00007fff82188fea _LSCopyLibraryItemURLs + 419
3 mdworker 0x0000000100004305 0x100000000 + 17157
4 mdworker 0x0000000100004c22 0x100000000 + 19490
5 mdworker 0x00000001000050f3 0x100000000 + 20723
6 mdworker 0x0000000100009aa2 0x100000000 + 39586
7 libSystem.B.dylib 0x00007fff80b94fd6 _pthread_start + 331
8 libSystem.B.dylib 0x00007fff80b94e89 thread_start + 13
[...]
Estoy razonablemente seguro de que esto no se debe al contenido de los archivos que intenta escanear, porque debería estar escaneando /Applications/
y opensnoop
no informa que toque ningún archivo allí (de hecho, la lista de archivos abiertos para cada UID 89 bloqueado instancia es idéntica, AFAICT).
Es posible que este problema esté relacionado con problemas que he tenido con Time Machine, que comenzó más o menos al mismo tiempo: backupd
también fallas de segmento inesperadas, no instantáneamente al inicio, sino en el proceso de montaje de mi volumen de copia de seguridad NAS. Aquí hay un extracto de un informe de bloqueo respaldado:
Thread 5 Crashed:
0 ...ple.CoreServices.CarbonCore 0x00007fff867e7f0b CSStoreGetUnit + 84
1 com.apple.LaunchServices 0x00007fff8217f3fb _LSBundleFindWithNode + 544
2 com.apple.LaunchServices 0x00007fff82177bd1 _LSFindOrRegisterBundleNode + 219
3 com.apple.LaunchServices 0x00007fff82177a85 _LSCopyItemAttributeForRefInfoWithOptions + 201
4 com.apple.LaunchServices 0x00007fff821799cf prepareAttributeValueForKey(__CFURL const*, __FileCache*, __CFString const*, void const**, __CFError**) + 79
5 com.apple.LaunchServices 0x00007fff82179934 prepareDistinctLocalizedNameValue(__CFURL const*, __FileCache*, __CFError**) + 36
6 com.apple.LaunchServices 0x00007fff8217990b prepareLocalizedNameValue(__CFURL const*, __FileCache*, __CFError**) + 9
7 com.apple.LaunchServices 0x00007fff82179712 LSPropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 51
8 ...ple.CoreServices.CarbonCore 0x00007fff867f8dd4 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 264
9 ...ple.CoreServices.CarbonCore 0x00007fff867f78bd _FSURLCopyResourcePropertiesForKeys + 980
10 com.apple.CoreFoundation 0x00007fff897dc562 CFURLCopyResourcePropertiesForKeys + 98
11 com.apple.DesktopServices 0x00007fff833737af TCFURLInfo::FetchProperties(bool) + 91
12 com.apple.DesktopServices 0x00007fff8337358f TCFURLInfo::Initialize(__CFURL const*, bool, bool) + 183
13 com.apple.DesktopServices 0x00007fff833d1acd TCFURLInfo::Initialize(char const*, unsigned int) + 89
14 com.apple.DesktopServices 0x00007fff833d369c TCFURLInfo::CreateDirectory(TUString const&, TUniqueNamer*, __FSFileSecurity*, bool, TCountedPtr<TCFURLInfo>&) const + 464
15 com.apple.DesktopServices 0x00007fff833dc95a TCopyWriter::CreateNewDestinationItem() + 178
16 com.apple.DesktopServices 0x00007fff833dd136 TCopyWriter::CreateItem() + 1126
17 com.apple.DesktopServices 0x00007fff833dd41e TCopyWriter::Write() + 146
18 com.apple.DesktopServices 0x00007fff833dd6a6 TCopyWriter::WriteTaskProc(void*) + 72
19 ...ple.CoreServices.CarbonCore 0x00007fff867e40d1 PrivateMPEntryPoint + 63
20 libSystem.B.dylib 0x00007fff80b94fd6 _pthread_start + 331
21 libSystem.B.dylib 0x00007fff80b94e89 thread_start + 13
He usado la Utilidad de Discos para (en vivo) verificar el volumen y reparar los permisos. He intentado volver a instalar la actualización combinada 1.1 10.6.8 y la actualización complementaria.
¿Qué podría estar causando estos bloqueos y cómo podría solucionarlo?
El problema fue causado por un caché corrupto de Launch Services y lo resolví ejecutando el siguiente comando:
sudo find /System/Library/Frameworks -type f -name lsregister -exec {} -kill -seed -r \;
La pista era que la falla de segmento estaba ocurriendo CSStoreGetUnit + 84
en ambos procesos; una búsqueda rápida en Google conduce a una entrada de blog que sugiere que la corrupción de la memoria caché podría ser el problema. En lugar de rm
enviar manualmente los archivos de caché, seguí las instrucciones que encontré en The X Lab , que equivalían a una explicación detallada de cómo abrir la terminal para ejecutar el comando mencionado anteriormente, señalando:
mdworker
funcionó bien como UID 501 (y varios otros), supuse que tendría que restablecer root
el caché de servicios de lanzamiento; el prefijo sudo
tuvo el efecto deseado.Notas adicionales:
En 10.8.6 (al menos) puede ver todos los archivos de caché de Launch Service con el siguiente comando:
sudo find /var/folders /Library/Caches/ -name '*LaunchServices*' -print0 |sudo xargs -0 ls -l
Por alguna razón desconocida, existe un archivo de caché modificado recientemente para UID 501 en ambos /Library/Caches/
y /var/folders/
; otros UID tienen solo uno debajo de /var/folders/
. Esto no parece causar ningún problema.
Esto resolvió el problema con backupd
.
ashley
cpcallen
/Applications/
deroot
, pero ni siquiera llega tan lejos.