6 votos

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

Mis ventiladores soplan constantemente, y una investigación de mi consola muestra este error que 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 creo recordar algunas más durante diferentes sesiones de observación de registros:

  • Twitter
  • com.apple.WebKit.Redes
  • 1Contraseña
  • cuentasd

He probado las siguientes cosas para solucionar el problema:

  1. Algunas excavaciones mostró este error podría estar relacionado con un problema de llavero. He borrado completamente mi llavero en un intento de reconstruir lo que faltaba, sin éxito.

    a. Tengo un crlcache.db referencia que parece muerta, pero ningún número de intentos de borrado hace que desaparezca.

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

  2. Una ejecución de Instrumentos con Actividad de Archivos observando el proceso de Twitter con la esperanza de averiguar qué archivo cree que está buscando (demasiado ruido y no estoy seguro de lo que estoy buscando).

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

  4. Una sesión de Recovery-Mode Disk Repair First Aid encontró un problema de catálogo con mi disco (1tb SSD de finales de 2013) y lo reparó con éxito. Esto está posiblemente relacionado con cualquier archivo que falta, pero ningún registro o aviso me dice que archivo que está buscando.

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

4voto

Howard Butler Puntos 131

Resolución

a. Tengo un crlcache.db referencia que parece muerta, pero ningún número de intentos de borrado hace que desaparezca.

Este era el problema de root, pero era difícil hacerlo desaparecer con alguna de las herramientas existentes. El crlcache.db La entrada estaba fantasma en mi aplicación Keychain Access, por lo que seguía existiendo una entrada. Aunque había restablecido todas mis contraseñas, no había matado del todo al Llavero. Todas las aplicaciones que enumeré estaban usando el Llavero para encontrar su información, pulsando crlcache.db y luego, ya sea reintentando o lanzando tuve que eliminar manualmente estos dos archivos (esencialmente un reinicio duro 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 recopilaba información sobre bugs para Apple, fue el más útil. Esto produjo un gigantesco tar.gz con un montón de cosas de diagnóstico que me dijeron mucho más sobre lo que estaba pasando. Asegúrese de ejecutar junto con cualquier aplicación (s) se está comportando mal en el momento.

sudo sysdiagnose securityd

Entre los muchos archivos de salida de depuración de texto plano que producía, había uno grande llamado fs_usage.txt y cuando lo abrí, pude ver 1000s de entradas conocidas

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. A falta de saber cómo realizar una cirugía laparoscópica en los archivos plist, simplemente amputé y volví a empezar.

1voto

Balázs Bábos Puntos 41

En mi caso después de eliminar Espionage dejó una referencia para su archivo .keychains en Keychain Access. Las entradas del 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 sencilla: tuve que eliminar la referencia de la base de datos en el Llavero de Acceso utilizando la entrada del menú en File llamado Delete Keychain Espionage . Debe intentar encontrar la referencia del archivo que falta en un DbOpen línea antes de la CSSM Exception líneas para ver lo que falta.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X