tl;dr

Wer in macOS gequält wird von einem Hintergrundprozess mit dem hübschen Namen lsd, der über längere Zeit mit 100% CPU-Last und enormem Speicherverbrauch den Mac lahmlegt, der kann das Problem meist mit dem folgenden Terminal-Befehl fixen:
Dazu muss er zuvor das Reparaturprogramm lsr dem Terminal einmalig zugänglich gemacht haben durch die beiden Befehle
In der Datei lsr all user,system,local.txt findet sich ein Protokoll der Reparatur.


IM EINZELNEN:

Das lsd-Problem

Seit einiger Zeit wurde mein Mac immer wieder mal für kurze Zeit zäh in der Reaktion oder blockierte völlig, gerne während Time Machine-Backups, aber nicht nur.

Ein Blick auf die Aktivitätsanzeige zeigte jedesmal denselben Schuldigen: einen wildlaufenden Hintergrundprozess (Dämon) namens lsd, der dann 99%-100% Rechenleistung und gigabyteweise Speicher beanspruchte. lsd? Ich frage mich bis heute, ob Steve Jobs bei der Namensgebung leise vor sich hingekichert hat; immerhin hat er ja erklärt, dass es ohne seine LSD-Erfahrungen den Mac nie gegeben hätte.

Aber was tut lsd (nicht LSD)? Bei Unix-Programmen pflegt man die zugehörige Manpage (Manual-Seite) zu fragen und die sagt:
Das ist alles. Danke, Apple; so genau wollte ich es gar nicht wissen. 🙄 Ob der Autor der Manpage wohl auch unter Drogen stand?

Tante Google sagt mir dann, dass

• ich wahrlich nicht der einzige mit diesem Problem bin
• das ls in lsd sich auf die Launch Services bezieht (das d meint wie üblich Dämon = Hintergrundprozess)

Es gibt natürlich auch diverse Lösungsbeschreibungen; die ich gefunden habe, sind aber alle nicht erschöpfend.

Daher hier eine systematische Zusammenfassung für alle, die von diesem Problem geplagt sind.


Die Launch Services-Datenbank(en)

Die Launch Services (Start-Dienste) sorgen dafür, dass Dateien jeweils mit für diesen Dateityp geeigneten, auf diesem Mac installierten Programmen gestartet werden. Diese Zuordnungen entnehmen die Launch Services jeweils einer in jeder App befindlichen plist (parameter list), die erklärt, welche Dateitypen die App öffnen kann; Ähnliches gilt für Plug-Ins, Dienste usw. Die Launch Services scannen diese plist in allen Apps, Diensten usw. und bauen daraus dann eine Datenbank. Manchmal kann man ja im Info-Fenster des Finders unter mehreren Apps diejenige wählen, die einen bestimmten Dateityp per Default öffnen soll; wenn man das tut, ändert man manuell einen Eintrag in eben jener Launch Services-Datenbank.

Diese Datenbanken (es gibt mehrere) geraten manchmal aufgrund irgendwelcher Bugs total aus den Fugen und das führt dann zu dem Problem, dass lsd – der sie ja laden muss – Massen von Speicher und Rechenleistung beansprucht und den Mac am Ende in die Knie zwingt.

Sowohl die Datenbanken als auch das zugehörige Konfigurationswerkzeug hat Apple aus irgendeinem Grund (LSD?) äußerst gut versteckt. Die Datenbanken findet Ihr im Finder wie folgt:

• Ihr geht mit Hilfe des Menüs Gehe zu → Gehe zum Ordner … zum unsichtbaren Ordner /private/var/folders/; das ist jener Ordner, wo Apple seit einiger Zeit viele wichtigen Konfigurationsdateien in einem undurchdringlichen Buchstabendschungel versteckt.
• Ihr gebt in das Suchfeld des Finder-Fensters com.apple.LaunchServices als Dateinamenssuche ein. Das funktioniert nur, wenn Ihr folders als Ausgangspunkt der Suche nehmt. Sonst findet Spotlight nichts, selbst wenn Ihr die zusätzliche Option Systemdateien einschließen gewählt habt!
• Es sollten Euch dann zwei Dateien mit dem Suffix .csstore angezeigt werden. Das sind zwei Launch Services-Datenbanken, eine für allgemein zugängliche Apps auf dem Mac und eine für Apps in Eurem Nutzerkonto (jeder Nutzer hat so eine nutzereigene Datenbank, die der anderen Nutzer seht Ihr aber natürlich nicht). Welche Datei welche Datenbank ist, könnt Ihr aus den zugehörigen Info-Fenstern entnehmen: die Datenbankdatei für allgemein zugängliche Apps gehört dem Nutzer System, ist aber für alle lesbar, Eure eigene gehört Euch und ist nur von Euch lesbar.

Diese Datenbanken sollten eine Größe im ein- bis zweistelligen Megabyte-Bereich haben. Als Anhaltspunkt: Ich habe auf meinem Mac Pro viele hundert Apps installiert; die systemweite Datenbank ist knappe 40 MB groß, meine private knappe 15 MB.

Das sind die Größen jetzt, wo alles wieder in Ordnung ist. Vor der Reparatur war die systemweite Datenbank aber satte 2 GB groß! Wenn Ihr bei Euch etwas auch nur annähernd Ähnliches seht, dann ist das Euer lsd-Problem. Falls nicht, ist es etwas anderes und ich weiß nicht, ob Euch die folgenden Schritte dann dennoch helfen werden (könnte sein).


Das Reparaturprogramm lsregister

Wie wird man nun die übergewichtige Datenbankdatei los? Einfach löschen geht nicht; lsd stellt sie sofort wieder her. Stattdessen muss man die komplette Datenbank reparieren; das Werkzeug dazu heißt lsregister und befindet sich im leicht zu merkenden Pfad /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/, den kein Mensch irgendwo eintippen will. Da dieser Pfad auch dem Terminal nicht bekannt ist als möglicher Pfad für Unix-Programme, kann man das Programm nicht einfach durch die Eingabe von lsregister starten.

Als Erstes erstellen wir daher einen Softlink von dem Programm nach /usr/local/bin/, einem Standardort, an dem Terminal Programme automatisch findet:
[Den Prompt % natürlich nicht mit eingeben!]
Ich habe zum einfacheren Tippen die abgekürzte Form lsr als Befehlsnamen gewählt, parallel zu lsd.

Versteckt, wie das Programm ist, gibt es natürlich keine Manpage. Die einzige Kurzanleitung bekommt man durch Aufruf des Programms selbst:

Um die Datenbank zu reparieren, müssen wir sie zuerst löschen und dann neu aufbauen. Gelöscht wird mit der Option -kill, das ist einfach. Schwieriger ist das erneute Aufbauen, wo genau angegeben werden muss, was berücksichtigt werden soll.

Man kann dazu einfach die Pfade zu den erneut zu registrierenden Apps, Diensten usw. beziehungsweise zu Ordnern, die solche Apps, Dienste usw. enthalten, angeben. Das ist nützlich, um gezielt einzelne Apps, Dienste usw. zu registrieren, aber wenn man das gesamte System neu aufbauen will, zu umständlich und fehleranfällig.

Vielversprechend ist daher die Option -seed, die verspricht, alle Standard-Orte für Apps, Dienste usw. zu scannen. Leider tut diese Option in Wirklichkeit aber das genaue Gegenteil: sie scannt den gesamten Mac. Zusätzliche macOS-Installationen auf getrennten Volumes, Apps, die statt zur Nutzung zu Dokumentation oder Erinnerung in irgendwelchen Dokumente-Unterordnern liegen, noch gar nicht näher betrachtete Apps in Downloads – nichts ist vor -seed sicher. So kommt man natürlich schnell auf viel zu große Datenbanken und völlig unübersichtliche Öffnen mit …-Listen im Finder. Bei mir hatte – das ist jetzt aber keine Schuld von -seed – die systemweite Launch Services-Datenbank aufgrund irgendeines Bugs sogar sämtliche Instanzen aller Apps in meinem Time Machine-Backup registriert: viele hundert Male TextEdit, viele hundert Male Vorschau … – so kommt man dann auf eine 2 GB große Datenbank.

-seed ist jedenfalls keine sinnvolle Option. Bleibt die Variante mit den „Domains“. Darunter versteht Apple die verschiedenen hierarchischen Bereiche von macOS, die Standard-Orte für Apps, Dienste usw. beinhalten. Die Aufteilung ist allerdings etwas seltsam. Die Domain user bezieht sich auf den Inhalt des eigenen, eindeutig abgegrenzten Nutzerordners (für jeden Nutzer ein eigener, den nur er mit dieser Domain ansprechen kann), das ist klar. local und system sind aber fast deckungsgleich; beide scannen alle Apps in /Programme/, local allerdings zusätzlich alles in /Library/ und system alles in /System/Library/. Man muss also trotz der Überschneidungen für eine vollständige Datenbank beide Domains angeben, keine Ahnung, was das soll. Wenigstens werden die Apps in /Programme/ dennoch nur einmal registriert. network schließlich soll augenscheinlich Programme, Dienste usw. scannen, die im Netzwerk verfügbar sind; was das heißt, konnte ich aber nicht herausfinden – bei mir blieb diese Domain immer leer oder erzeugte sogar Fehler, auch wenn sich im lokalen Netzwerk mehrere andere wache Macs befanden und im Finder miteinander verbunden waren. Diese Domain sollte man also wohl ignorieren.

Die Domains werden kombiniert mit entweder der Option -apps (nur Apps werden gescannt) oder -libs (die Library-Ordner werden nach Diensten, Plug-Ins usw. gescannt) oder -all (beides kombiniert). Für einen Neuaufbau der Datenbank ist natürlich nur -all sinnvoll. (Die Optionen -apps, -libs und -all schließen sich gegenseitig aus, d.h. man kann sie nicht für eine präzisere Auswahl kombinieren.)

Die Domains können der Kürze halber auch durch ihren Anfangsbuchstaben spezifiziert werden. Die komplette Option für die Orte, aus denen die Datenbank neu aufgebaut werden soll, lautet dann also -all u,l,s. Gefunden werden damit Apps, Dienste usw., die sich in einem der Programme-Ordner oder einem der Library-Ordner befinden.


Der Ordner für nutzerspezifische Programme

Die Suche in Programme-Ordnern hat allerdings einen Haken: Der Ordner ~/Programme/ im Heimordner des Nutzers für nur ihm zugängliche Apps ist zwar vorgesehen, wird aber beim Anlegen eines neuen Nutzers nicht automatisch in seinem Heimordner erzeugt. Er muss ggf. für nutzerspezifische Programme erst noch angelegt werden, und zwar wie bei /Programme/ und anderen systemrelevanten Ordnern auch in Englisch, also als ~/Applications/. Das könnte man zwar im Finder machen, aber nachdem danach ohnehin noch zwei Terminal-Befehle notwendig sind, kann man das auch gleich dort erledigen:
Mit diesem Befehl wird nicht nur der Ordner Applications im Heimorder angelegt, sondern auch mit den korrekten Zugriffsrechten versehen; die in dem Ordner erzeugte, unsichtbare und leere Datei .localized sorgt dafür, dass der Ordner im Finder mit dem Namen Programme angezeigt wird.


Der Reparaturbefehl

Der Kernbefehl für das Löschen und dann den Neuaufbau der Launch Services-Datenbank lautet also
Um aber eine Kontrolle über das Ergebnis zu haben, habe ich für den kompletten Befehl eine Ausgabe aller registrierten Objekte in eine Datei lsr all user,local,system.txt angehängt, die nach Neuaufbau der Datenbank (der einige Minuten dauern kann) automatisch in TextEdit geöffnet wird:

Aller Code beginnend mit -v dient nur diesem Zweck und soll hier nicht näher besprochen werden. Der Dateiname lsr all user,local,system.txt benennt zur Erinnerung den prinzipiellen Befehl, mit dem sie erzeugt wurde; man kann natürlich auch einen anderen Namen verwenden, der dann beide Male in obiger Befehlszeile ausgetauscht werden muss.

Mit diesem Befehl werden alle Objekte in den Programme- und Library-Ordnern neu registriert. Das heißt aber nicht, dass die Launch Services-Datenbank zukünftig auf diese Orte beschränkt bleibt. Wird nach dem Neuaufbau der Launch Services-Datenbank irgendwo außerhalb dieser Orte eine App einmal gestartet, so wird sie sofort registriert (wie natürlich auch neue Apps innerhalb dieser Orte). Aber sie muss eben tatsächlich gestartet werden; ungenutzte Apps bleiben unregistriert, und so soll es auch sein. Insofern ist es normal, dass die Größe der Launch Services-Datenbank allmählich wächst; sie darf eben nur nicht wuchern.


Ärzte und Apotheker zu den Nebenwirkungen

Mit dem Neuaufbau der Launch Services-Datenbank werden leider auch alle individuellen Dateizuordnungen, die Ihr im Laufe der Zeit vorgenommen habt, gelöscht (also z.B., dass .png-Bilder in Affinity Photo statt Vorschau geöffnet werden); sie müssen daher neu konfiguriert werden. Insofern ist der Neuaufbau der Launch Services-Datenbank eine Rosskur, die nur vorgenommen werden sollte, wenn unbedingt nötig.

Da sage ich doch mal ein dickes Danke für die Tipps und Erklärungen zu dieser Problematik!

Soweit ich weiß, kann man mit dem TinkerTool System von Marcel Bresink die Launch-Services Datenbank mit einem Klick neu aufbauen:

Mal Wiedereinführung typischer Weia-Artikel. Wenn er was schreibt, dann aber gründlich herzlichen Dank für die ausführliche Erklärung.
Fehlt nur das Tltr am Anfang mit Hinweis auf den Apothekersatz am Ende

Praktisch wäre natürlich noch, wenn man seine Sonderlocken vorher noch irgendwie exportieren könnte (sofern da noch bei einer defekten Datenbank möglich ist)? Und anschließend wieder importieren…

Das stimmt, aber (zumindest in meiner Version 6.99/Mojave) nur mit der aus meiner Sicht unbrauchbaren -seed-Option (wie es ja allgemein ein Problem solcher GUI-Wrapper um Unix-Programme ist, dass sie die vielfältigen Einstellmöglichkeiten massiv bis vollständig beschneiden).

Zum Vergleich beispielhaft auf meinem Mac:

mein Vorschlag (hier ohne Textformatierung) ≙ lsr -kill -all u,l,s -v:

• registrierte Apps: 916
• Scandauer: 3 Minuten
• Protokoll: 1 Zeile pro Eintrag, gut als Übersicht (mit der Option -dump ließe sich auch TinkerTool Systems Variante ausgeben)

TinkerTool System ≙ lsr -kill -seed -dump:

• registrierte Apps: 1996 (also über 1000 mutmaßliche Karteileichen oder Apps aus anderen macOS-Installationen)
• Scandauer: 13 Minuten
• Protokoll: extrem detailliert, als Übersicht daher nicht geeignet

Und ob ich nun in TinkerTool System den entsprechenden Bereich auswähle und einmal klicke oder den lsr-Befehl kopiere und in Terminal paste …

Vor allem ging es mir in dem Beitrag ja aber auch um ein Verständnis der Hintergründe.

WOW!
@Weia, Danke auch von mir für diese ausführliche Zusammenfassung, Übersetzung und Beschreibung!
bis man das einzeln aus dem Internet rausgefieselt hat dauert's.

Sollte das nicht so lauten?


Also mit Tilde.

Nö. cd ohne Argument ist äquivalent zu cd ~.

Ah, interessant. Sogar in sh. Ich dachte bisher, das können nur gewisse Shells.

sh ist die gewisseste aller Shells.

2 Monate später …

Zunächst mal ein Erratum:

In meiner Erinnerung bin ich mir zu 119,83% sicher, dass ich, bevor ich den Reparaturbefehl hier gepostet habe, überprüft habe, ob man den als root ausführen, also ein sudo voranstellen muss, denn davon ging ich eigentlich aus. Zu meiner Überraschung, so das damalige Ergebnis der Überprüfung, war das aber nicht erforderlich.

Ich weiß nicht, was ich damals falsch gemacht habe, aber das Ergebnis stimmt nicht – man braucht (wenig überraschend) doch sudo. Das bringt aber ein neues Problem mit sich, nämlich, dass die zu reparierende Datenbank nun nicht mehr die eigene ist, sondern die von root, was natürlich nicht beabsichtigt ist.

De facto muss man also den Befehl auftrennen und die systemweite Datenbank mit sudo reparieren, die eigene aber unter eigenem Namen. Nachdem das endgültig zu kompliziert für einen Befehl zum Kopieren und Einfügen ist, habe ich ein kleines Skript daraus gemacht, das ich unter dem Namen resetLSD in /usr/local/bin/ abgespeichert habe:
Der Terminal-Befehl resetLSD protokolliert alle registrierten Programme in einer Datei mit einem Namen wie resetLSD Sa 23 Sep 2023 18:14:58 CEST.txt im aktuellen Ordner – ohne weiteres Zutun in einem neuen Terminal-Fenster also im Heimordner. Es darf nicht mit sudo aufgerufen werden, sondern fragt, wo nötig, eigenständig nach dem Administrator-Passwort, das dann eingegeben werden muss!


Bei mir ging der Kladderadatsch mit der rapide anwachsenden Dateigröße aber sofort wieder von vorne los. Um das besser beobachten zu können, habe ich ein weiteres Skript geschrieben, checkLSD, und ebenfalls in /usr/local/bin/ abgespeichert:
Dieses Skript wertet den Inhalt der Launch Services-Datenbank im Hinblick auf Zahl der registrierten Programme und die Dateigröße der Datenbank aus; überprüft ist die Funktionsfähigkeit auf Mojave, es sollte aber auch auf anderen macOS-Versionen laufen.

Das Skript liest Dateien lediglich und verändert sie nicht; man kann es also jederzeit gefahrlos als normaler Nutzer laufen lassen. sudo darf nicht verwendet werden (sonst bekommt man die Nutzerdatenbank des Nutzers root angezeigt)! Allerdings braucht auch dieses Skript seine Zeit von ein, zwei Minuten.

Die Auswertung erfolgt heuristisch, das ich das interne Datenbankformat ja nicht kenne; das Ergebnis sollte aber in etwa stimmen.

Nach einer neu mit resetLSD zurückgesetzten Launch Services-Datenbank sieht die Ausgabe im Terminal bei mir so aus:

Das ganze Desaster erkennt man, wenn man die Ausgabe von checkLSD vor resetLSD damit vergleicht:
Das war nach 2 Monaten ohne Reset der Datenbank.

Ob das ein Bug nur auf meiner macOS-Installation, nur auf Mojave oder generell auf macOS ist – keine Ahnung.

Mich würde natürlich sehr interessieren, was checkLSD auf Euren Macs so anzeigt. Wie gesagt, Ihr könnt es völlig gefahrlos ausprobieren; verändern täte nur resetLSD etwas. Falls es jemand hier posten mag, bitte immer die macOS-Version dazu angeben.

Zu Beginn des Skripts versucht checkLSD, die genauen Dateipfade für die beiden Datenbankdateien automatisch zu ermitteln, die ja bei jeder macOS-Installation andere sind. marm hat mich darauf aufmerksam gemacht, dass das bei ihm (Ventura) aufgrund mangelnder Zugriffsrechte in der /var/folders/-Hierarchie nicht funktioniert und daher das gesamte Skript scheitert.

Ob das bei mir funktioniert, weil ich noch auf Mojave bin oder weil ich SIP ausgeschaltet habe, kann ich nicht sagen und ich kann mich aufgrund Zeitmangels in den nächsten zwei bis drei Wochen leider auch nicht darum kümmern.

Eventuell muss man dem Terminal Festplattenvollzugriff gewähren.