Nächste: guix pull
aufrufen, Vorige: Pakete mit mehreren Ausgaben., Nach oben: Paketverwaltung [Inhalt][Index]
guix gc
aufrufenPakete, 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.
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
).
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.
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]