Meine Fans blasen ständig und eine Untersuchung meiner Konsole zeigt, 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 erinnere mich anscheinend noch an ein paar weitere während verschiedener Protokollbeobachtungssitzungen:

• Twitter
• com.apple.WebKit.Networking
• 1Passwort
• accountsd

Ich habe die folgenden Dinge versucht, um das Problem zu lösen:

1. Einige Grabungen haben gezeigt, dass dieser Fehler möglicherweise mit einem Schlüsselbundproblem zusammenhängt. Ich habe meinen Schlüsselbund komplett nuked, um ihn dazu zu bringen, alles, was fehlte, ohne Erfolg wieder aufzubauen.

   ein. Ich habe einen crlcache.dbHinweis, der tot zu sein scheint, aber keine Anzahl von Löschversuchen lässt ihn verschwinden.

   b. Bevor ich alles kaputt gemacht habe, habe ich versucht, tote Zertifikate ohne Glück wegzuwischen.

2. Ein Instrument läuft mit File Activity und beobachtet den Twitter-Prozess in der Hoffnung, herauszufinden, nach welcher Datei es sucht (zu laut und ich bin nicht sicher, wonach ich suche).

3. Eine vollständige Überinstallation eines neuen 10.12.4 Sierra-Downloads hat 30 Minuten gedauert, aber sonst nichts getan, um Abhilfe zu schaffen.

4. In einer Erste-Hilfe-Sitzung zur Festplattenreparatur im Wiederherstellungsmodus wurde ein Katalogproblem mit meiner Festplatte (1 TB SSD, Ende 2013) festgestellt und erfolgreich repariert. Dies hängt möglicherweise mit der fehlenden Datei zusammen, aber kein Protokoll oder Hinweis gibt Auskunft darüber, nach welcher Datei gesucht wird.

Irgendwelche Tipps für andere Dinge zum Ausprobieren? Ich verwende Sierra 10.12.4 auf einem 15-Zoll-MBP von Ende 2013 mit einer 1-TB-SSD.

Auflösung

ein. Ich habe einen crlcache.dbHinweis, der tot zu sein scheint, aber keine Anzahl von Löschversuchen lässt ihn verschwinden.

Dies war das Hauptproblem, aber es war schwierig, es mit einem der vorhandenen Tools zu beseitigen. Der crlcache.dbEintrag wurde in meiner Anwendung für den Schlüsselbund-Zugriff als "Ghost" angezeigt, sodass noch ein Eintrag vorhanden war. Während ich alle meine Passwörter zurückgesetzt hatte, hatte ich den Schlüsselbund nicht vollständig gelöscht. Alle Anwendungen, die ich auflistete, verwendeten den Schlüsselbund, um ihre Informationen zu finden, zu treffen crlcache.dbund dann entweder erneut zu versuchen oder zu werfen. Ich musste beide Dateien manuell entfernen (im Wesentlichen ein Hard-Reset des gesamten Schlüsselbunds):

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

Diagnose

Es war sehr schwierig, das Problem zu diagnostizieren, da mir nichts sagen würde, welche Datei nicht existiert. Dieser Kommentar mit seinem Befehl, der Fehlerinformationen für Apple sammelte, war am hilfreichsten. Dies brachte einen Riesen tar.gzmit vielen diagnostischen Extras hervor, der mir viel mehr über die Vorgänge erzählte. Stellen Sie sicher, dass Sie mit allen Anwendungen ausgeführt werden, die sich zu diesem Zeitpunkt fehlerhaft verhalten.

sudo sysdiagnose securityd

Unter den vielen Klartext-Debug-Ausgabedateien, die es erzeugte, gab es eine große mit dem Namen fs_usage.txt, und als ich sie öffnete, konnte ich Tausende von vertrauten 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 gespenstischer Eintrag musste verschwinden. Da ich nicht weiß, wie man laparoskopische Operationen an den Plist-Akten durchführt, habe ich einfach amputiert und neu angefangen.

In meinem Fall hinterließ es nach dem Entfernen von Espionage eine Referenz für die .keychains-Datei in Keychain Access. Logeinträge waren wie folgt:

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 Auflösung war eher simpel: Musste den Datenbankverweis im Schlüsselbund über den Menüeintrag im Fileaufgerufenen entfernen Delete Keychain Espionage. Sie sollten versuchen, den fehlenden Dateiverweis in einer DbOpenZeile vor den CSSM ExceptionZeilen zu suchen, um festzustellen , was fehlt.