Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]


6.5 guix gc aufrufen

Pakete, die zwar installiert sind, aber nicht benutzt werden, können vom Müllsammler entfernt werden. Mit dem Befehl guix gc können Benutzer den Müllsammler ausdrücklich aufrufen, um Speicher im Verzeichnis /gnu/store freizugeben. Dies ist der einzige Weg, Dateien aus /gnu/store zu entfernen – das manuelle Entfernen von Dateien kann den Store irreparabel beschädigen!

Der Müllsammler kennt eine Reihe von Wurzeln: Jede Datei in /gnu/store, die von einer Wurzel aus erreichbar ist, gilt als lebendig und kann nicht entfernt werden; jede andere Datei gilt als tot und ist ein Kandidat, gelöscht zu werden. Die Menge der Müllsammlerwurzeln (kurz auch „GC-Wurzeln“, von englisch „Garbage Collector“) umfasst Standard-Benutzerprofile; standardmäßig werden diese Müllsammlerwurzeln durch symbolische Verknüpfungen in /var/guix/gcroots dargestellt. Neue Müllsammlerwurzeln können zum Beispiel mit guix build --root festgelegt werden (siehe Aufruf von guix build). Der Befehl guix gc --list-roots listet sie auf.

Bevor Sie mit guix gc --collect-garbage Speicher freimachen, wollen Sie vielleicht alte Generationen von Benutzerprofilen löschen, damit alte Paketerstellungen von diesen Generationen entfernt werden können. Führen Sie dazu guix package --delete-generations aus (siehe guix package aufrufen).

Unsere Empfehlung ist, dass Sie den Müllsammler regelmäßig laufen lassen und wenn Sie wenig freien Speicherplatz zur Verfügung haben. Um zum Beispiel sicherzustellen, dass Sie mindestens 5 GB auf Ihrer Platte zur Verfügung haben, benutzen Sie einfach:

guix gc -F 5G

Es ist völlig sicher, dafür eine nicht interaktive, regelmäßige Auftragsausführung vorzugeben (siehe Geplante Auftragsausführung für eine Erklärung, wie man das tun kann). guix gc ohne Befehlszeilenargumente auszuführen, lässt so viel Müll wie möglich sammeln, aber das ist oft nicht, was man will, denn so muss man unter Umständen Software erneut erstellen oder erneut herunterladen, weil der Müllsammler sie als „tot“ ansieht, sie aber zur Erstellung anderer Software wieder gebraucht wird – das trifft zum Beispiel auf die Compiler-Toolchain zu.

Der Befehl guix gc hat drei Arbeitsmodi: Er kann benutzt werden, um als Müllsammler tote Dateien zu entfernen (das Standardverhalten), um ganz bestimmte, angegebene Datein zu löschen (mit der Befehlszeilenoption --delete), um Müllsammlerinformationen auszugeben oder fortgeschrittenere Anfragen zu verarbeiten. Die Müllsammler-Befehlszeilenoptionen sind wie folgt:

--collect-garbage[=Minimum]
-C [Minimum]

Lässt Müll sammeln – z.B. nicht erreichbare Dateien in /gnu/store und seinen Unterverzeichnissen. Wird keine andere Befehlszeilenoption angegeben, wird standardmäßig diese durchgeführt.

Wenn ein Minimum angegeben wurde, hört der Müllsammler auf, sobald Minimum Bytes gesammelt wurden. Das Minimum kann die Anzahl der Bytes bezeichnen oder mit einer Einheit als Suffix versehen sein, wie etwa MiB für Mebibytes und GB für Gigabytes (siehe Größenangaben in GNU Coreutils).

Wird kein Minimum angegeben, sammelt der Müllsammler allen Müll.

--free-space=Menge
-F Menge

Sammelt Müll, bis die angegebene Menge an freiem Speicher in /gnu/store zur Verfügung steht, falls möglich; die Menge ist eine Speichergröße wie 500MiB, wie oben beschrieben.

Wenn die angegebene Menge oder mehr bereits in /gnu/store frei verfügbar ist, passiert nichts.

--delete-generations[=Dauer]
-d [Dauer]

Bevor der Müllsammelvorgang beginnt, werden hiermit alle Generationen von allen Benutzerprofilen und von allen Persönlichen Umgebungen gelöscht, die älter sind als die angegebene Dauer; wird es als Administratornutzer „root“ ausgeführt, geschieht dies mit den Profilen von allen Benutzern.

Zum Beispiel löscht der folgende Befehl alle Generationen Ihrer Profile, die älter als zwei Monate sind (ausgenommen die momentanen Generationen), und schmeißt dann den Müllsammler an, um Platz freizuräumen, bis mindestens 10 GiB verfügbar sind:

guix gc -d 2m -F 10G
--delete
-D

Versucht, alle als Argumente angegebenen Dateien oder Verzeichnisse im Store zu löschen. Dies schlägt fehl, wenn manche der Dateien oder Verzeichnisse nicht im Store oder noch immer lebendig sind.

--list-failures

Store-Objekte auflisten, die zwischengespeicherten Erstellungsfehlern entsprechen.

Hierbei wird nichts ausgegeben, sofern der Daemon nicht mit --cache-failures gestartet wurde (siehe --cache-failures).

--list-roots

Die Müllsammlerwurzeln auflisten, die dem Nutzer gehören. Wird der Befehl als Administratornutzer ausgeführt, werden alle Müllsammlerwurzeln aufgelistet.

--list-busy

Solche Store-Objekte auflisten, die von aktuell laufenden Prozessen benutzt werden. Diese Store-Objekte werden praktisch wie Müllsammlerwurzeln behandelt; sie können nicht gelöscht werden.

--clear-failures

Die angegebenen Store-Objekte aus dem Zwischenspeicher für fehlgeschlagene Erstellungen entfernen.

Auch diese Option macht nur Sinn, wenn der Daemon mit --cache-failures gestartet wurde. Andernfalls passiert nichts.

--list-dead

Zeigt die Liste toter Dateien und Verzeichnisse an, die sich noch im Store befinden – das heißt, Dateien, die von keiner Wurzel mehr erreichbar sind.

--list-live

Zeige die Liste lebendiger Store-Dateien und -Verzeichnisse.

Außerdem können Referenzen unter bestehenden Store-Dateien gefunden werden:

--references
--referrers

Listet die referenzierten bzw. sie referenzierenden Objekte der angegebenen Store-Dateien auf.

--requisites
-R

Listet alle Voraussetzungen der als Argumente übergebenen Store-Dateien auf. Voraussetzungen sind die Store-Dateien selbst, ihre Referenzen sowie die Referenzen davon, rekursiv. Mit anderen Worten, die zurückgelieferte Liste ist der transitive Abschluss dieser Store-Dateien.

Der Abschnitt guix size aufrufen erklärt ein Werkzeug, um den Speicherbedarf des Abschlusses eines Elements zu ermitteln. Siehe guix graph aufrufen für ein Werkzeug, um den Referenzgraphen zu veranschaulichen.

--derivers

Liefert die Ableitung(en), die zu den angegebenen Store-Objekten führen (siehe Ableitungen).

Zum Beispiel liefert dieser Befehl:

guix gc --derivers $(guix package -I ^emacs$ | cut -f4)

die .drv-Datei(en), die zum in Ihrem Profil installierten emacs-Paket führen.

Beachten Sie, dass es auch sein kann, dass keine passenden .drv-Dateien existieren, zum Beispiel wenn diese Dateien bereits dem Müllsammler zum Opfer gefallen sind. Es kann auch passieren, dass es mehr als eine passende .drv gibt, bei Ableitungen mit fester Ausgabe.

Zuletzt können Sie mit folgenden Befehlszeilenoptionen die Integrität des Stores prüfen und den Plattenspeicherverbrauch im Zaum halten.

--verify[=Optionen]

Die Integrität des Stores verifizieren

Standardmäßig wird sichergestellt, dass alle Store-Objekte, die in der Datenbank des Daemons als gültig markiert wurden, auch tatsächlich in /gnu/store existieren.

Wenn angegeben, müssen die Optionen eine kommagetrennte Liste aus mindestens einem der Worte contents und repair sein.

Wenn Sie --verify=contents übergeben, berechnet der Daemon den Hash des Inhalts jedes Store-Objekts und vergleicht ihn mit dem Hash in der Datenbank. Sind die Hashes ungleich, wird eine Datenbeschädigung gemeldet. Weil dabei alle Dateien im Store durchlaufen werden, kann der Befehl viel Zeit brauchen, besonders auf Systemen mit langsamer Platte.

Mit --verify=repair oder --verify=contents,repair versucht der Daemon, beschädigte Store-Objekte zu reparieren, indem er Substitute für selbige herunterlädt (siehe Substitute). Weil die Reparatur nicht atomar und daher womöglich riskant ist, kann nur der Systemadministrator den Befehl benutzen. Eine weniger aufwendige Alternative, wenn Sie wissen, welches Objekt beschädigt ist, ist, guix build --repair zu benutzen (siehe Aufruf von guix build).

--optimize

Den Store durch Nutzung harter Verknüpfungen für identische Dateien optimieren – mit anderen Worten wird der Store dedupliziert.

Der Daemon führt Deduplizierung automatisch nach jeder erfolgreichen Erstellung und jedem Importieren eines Archivs durch, sofern er nicht mit --disable-deduplication (siehe --disable-deduplication) gestartet wurde. Diese Befehlszeilenoption brauchen Sie also in erster Linie dann, wenn der Daemon zuvor mit --disable-deduplication gestartet worden ist.

--vacuum-database

Für Guix wird eine SQLite-Datenbank verwendet, um über die Objekte im Store Buch zu führen (siehe Der Store). Mit der Zeit kann die Datenbank jedoch eine gigantische Größe erreichen und fragmentieren. Deshalb kann es sich lohnen, den freien Speicher aufzuräumen und nur teilweise genutzte Datenbankseiten, die beim Löschen von Paketen bzw. nach dem Müllsammeln entstanden sind, zusammenzulegen. Führen Sie sudo guix gc --vacuum-database aus, und die Datenbank wird gesperrt und eine VACUUM-Operation auf dem Store durchgeführt, welche die Datenbank defragmentiert und leere Seiten wegschafft. Wenn alles fertig ist, wird die Datenbank entsperrt.


Nächste: guix pull aufrufen, Vorige: Pakete mit mehreren Ausgaben., Nach oben: Paketverwaltung   [Inhalt][Index]