Meine Lüfter blasen ständig, und einige Untersuchungen meiner Konsole zeigen, dass dieser Fehler mit einer fantastischen Geschwindigkeit ausgespuckt wird
CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
Und
dbBlobVersion() failed for a non-existent database
Die folgenden Anwendungen produzieren es, aber ich scheine mich an ein paar mehr während verschiedener Sitzungen zum Ansehen von Protokollen zu erinnern:
Ich habe folgende Dinge versucht, um das Problem zu lösen:
Einige Recherchen zeigten , dass dieser Fehler möglicherweise mit einem Problem mit dem Schlüsselbund zusammenhängt. Ich habe meinen Schlüsselbund komplett vernichtet, um ihn dazu zu bringen, das, was fehlte, wieder aufzubauen, ohne Erfolg.
A. Ich habe eine crlcache.dbReferenz, die tot zu sein scheint, aber keine Anzahl von Löschversuchen lässt sie verschwinden.
B. Bevor ich alles vernichtete, versuchte ich erfolglos, tote Zertifikate wegzuwischen.
Ein Instruments-Lauf mit Dateiaktivität, der den Twitter-Prozess beobachtet, in der Hoffnung, herauszufinden, nach welcher Datei er sucht (zu laut und ich bin mir nicht sicher, wonach ich suche).
Eine vollständige Überinstallation eines frischen 10.12.4 Sierra-Downloads hat 30 Minuten gedauert, aber nichts anderes getan, um die Situation zu beheben.
Eine Erste-Hilfe-Sitzung zur Festplattenreparatur im Wiederherstellungsmodus hat ein Katalogproblem mit meiner Festplatte (Ende 2013 1 TB SSD) gefunden und erfolgreich repariert. Dies hängt möglicherweise mit der fehlenden Datei zusammen, aber kein Protokoll oder Hinweis sagt mir, nach welcher Datei gesucht wird.
Irgendwelche Tipps für andere Dinge zu versuchen? Ich verwende Sierra 10.12.4 auf einem 15-Zoll-MBP von Ende 2013 mit einer 1-TB-SSD.
A. Ich habe eine
crlcache.dbReferenz, die tot zu sein scheint, aber keine Anzahl von Löschversuchen lässt sie verschwinden.
Dies war das Grundproblem, aber es war schwierig, es mit einem der vorhandenen Tools zu beseitigen. Der crlcache.dbEintrag wurde in meiner Anwendung „Schlüsselbundverwaltung“ verworfen, sodass noch ein Eintrag vorhanden war. Obwohl ich alle meine Passwörter zurückgesetzt hatte, hatte ich den Schlüsselbund nicht vollständig gelöscht. Alle Anwendungen, die ich aufgelistet habe, verwendeten den Schlüsselbund, um ihre Informationen zu finden, zu treffen crlcache.dbund dann entweder erneut zu versuchen oder zu werfen. Ich musste diese beiden Dateien manuell entfernen (im Wesentlichen ein Hard-Reset des gesamten Schlüsselbunds):
~/Library/Preferences/com.apple.security.plist
/Library/Preferences/com.apple.security.plist
Es war sehr schwierig, das Problem zu diagnostizieren, da mir nichts sagen konnte, welche Datei nicht existierte. Dieser Kommentar mit seinem Befehl, der Fehlerinformationen für Apple sammelte, war am hilfreichsten. Daraus entstand ein Riese tar.gzmit vielen diagnostischen Goodies, die mir viel mehr darüber verrieten, was vor sich ging. Stellen Sie sicher, dass Sie mit allen Anwendungen mitlaufen, die sich zu diesem Zeitpunkt schlecht verhalten.
sudo sysdiagnose securityd
Unter den vielen Klartext-Debug-Ausgabedateien, die es erzeugte, gab es eine große namens fs_usage.txt, und als ich sie öffnete, konnte ich Tausende von bekannten Einträgen sehen
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
Als ich das sah, war klar, dass der Schlüsselbund immer noch das Problem war, und mein geisterhafter Eintrag musste verschwinden. Da ich nicht wusste, wie man laparoskopische Operationen an den Plist-Dateien durchführt, amputierte ich einfach und fing von vorne an.
In meinem Fall hinterließ es nach dem Entfernen von Spionage eine Referenz für seine .keychains-Datei in Keychain Access. Log-Einträge sahen so aus:
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
Die Lösung war ziemlich einfach: musste die Datenbankreferenz in der Schlüsselbundverwaltung über den Menüeintrag in Fileaufgerufen entfernen Delete Keychain Espionage. Sie sollten versuchen, die fehlende Dateireferenz in einer DbOpenZeile vor den CSSM ExceptionZeilen zu finden, um zu sehen, was fehlt.