¿Cómo identificar un almacén de datos faltante para com.apple.securityd?

Mis ventiladores están soplando constantemente, y una investigación de mi Consola muestra que este error se escupe a un ritmo fantástico

CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST

y

dbBlobVersion() failed for a non-existent database

Las siguientes aplicaciones lo están produciendo, pero me parece recordar algunas más durante diferentes sesiones de visualización de registros:

  • Gorjeo
  • com.apple.WebKit.Networking
  • 1 Contraseña
  • cuentas

He intentado las siguientes cosas para resolver el problema:

  1. Algunas excavaciones mostraron que este error podría estar relacionado con un problema de llavero. Destruí por completo mi llavero en un intento de que reconstruyera lo que faltaba sin éxito.

    a. Tengo una crlcache.dbreferencia que parece muerta, pero ningún número de intentos de eliminación hace que desaparezca.

    b. Antes de bombardear todo, intenté borrar los certificados muertos sin suerte.

  2. Un instrumento se ejecuta con Actividad de archivo observando el proceso de Twitter con la esperanza de descubrir qué archivo cree que está buscando (demasiado ruido y no estoy seguro de lo que estoy buscando).

  3. Una sobreinstalación completa de una nueva descarga de Sierra 10.12.4 duró 30 minutos, pero no hizo nada más para remediar la situación.

  4. Una sesión de primeros auxilios de reparación de disco en modo de recuperación encontró un problema de catálogo con mi disco (SSD de 1 tb de finales de 2013) y lo reparó con éxito. Esto posiblemente esté relacionado con cualquier archivo que falte, pero ningún registro o aviso me dice qué archivo está buscando.

¿Algún consejo para probar otras cosas? Estoy ejecutando Sierra 10.12.4 en un MBP de 15 "de finales de 2013 con un SSD de 1 tb.

Respuestas (2)

Resolución

a. Tengo una crlcache.dbreferencia que parece muerta, pero ningún número de intentos de eliminación hace que desaparezca.

Este era el problema de raíz, pero era difícil hacerlo desaparecer con cualquiera de las herramientas existentes. La crlcache.dbentrada estaba oculta en mi aplicación Acceso a Llaveros, por lo que aún existía una entrada. Si bien había restablecido todas mis contraseñas, no había eliminado por completo el llavero. Todas las aplicaciones que enumeré estaban usando el llavero para encontrar su información, presionando crlcache.dby luego reintentando o tirando. Tuve que eliminar manualmente estos dos archivos (esencialmente un restablecimiento completo de todo el llavero):

~/Library/Preferences/com.apple.security.plist
/Library/Preferences/com.apple.security.plist

Diagnóstico

Fue muy difícil diagnosticar el problema porque nada me decía qué archivo no existía. Este comentario , con su comando que recopiló información de errores para Apple, fue el más útil. Esto produjo un gigante tar.gzcon muchas cosas valiosas de diagnóstico que me dijeron mucho más sobre lo que estaba pasando. Asegúrese de ejecutar junto con cualquier aplicación que se esté comportando mal en ese momento.

sudo sysdiagnose securityd

Entre los muchos archivos de salida de depuración de texto sin formato que produjo, había uno grande llamado fs_usage.txt, y cuando lo abrí, pude ver miles de entradas familiares

08:01:11.999993  getattrlist                            /private/var                                                                                                                                                          0.000003   Twitter.3616
08:01:11.999996  getattrlist                            /private/var/db                                                                                                                                                       0.000003   Twitter.3616
08:01:11.999998  getattrlist                            /private/var/db/crls                                                                                                                                                  0.000003   Twitter.3616
08:01:12.000000  getattrlist            [  2]           /private/var/db/crls/crlcache.db                                                                                                                                      0.000002   Twitter.3616
08:01:12.000004  statfs64                               /private/var/db/crls      

Una vez que vi eso, estaba claro que el llavero seguía siendo el problema, y ​​mi entrada fantasma tenía que desaparecer. Al carecer del conocimiento de cómo realizar una cirugía laparoscópica en los archivos plist, simplemente amputé y comencé de nuevo.

En mi caso, después de eliminar Espionage, dejó una referencia para su archivo .keychains en Acceso a Llaveros. Las entradas de registro eran como estas:

default 15:11:56.715938 +0200   com.apple.WebKit.Networking DbOpen of /Volumes/1Tb/Users/MyUser/Library/Application Support/Espionage/Espionage.keychain
default 15:11:56.716702 +0200   com.apple.WebKit.Networking open /Volumes/1Tb/Users/MyUser/Library/Application Support/Espionage/Espionage.keychain: No such file or directory
default 15:11:56.716765 +0200   com.apple.WebKit.Networking CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 15:11:56.716848 +0200   com.apple.WebKit.Networking CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 15:11:56.716910 +0200   com.apple.WebKit.Networking CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 15:11:56.716952 +0200   com.apple.WebKit.Networking dbBlobVersion() failed for a non-existent database

La resolución fue bastante simple: tuvo que eliminar la referencia de la base de datos en Acceso a Llaveros usando la entrada de menú en Filecalled Delete Keychain Espionage. Debe intentar encontrar la referencia del archivo que falta en una DbOpenlínea antes de las CSSM Exceptionlíneas para ver qué falta.