it-know-how/Linux/Pacman Paketcache verwalten.md

Pacman Paketcache verwalten (paccache)

Pacman lädt jedes Paket als .pkg.tar.zst nach /var/cache/pacman/pkg und löscht es danach nicht mehr. Der Cache wächst dadurch unbegrenzt – auf diesem System waren es einmal 66 GB, was den Plattenplatz deutlich stärker belegte als der gesamte AUR-Cache (~/.cache/yay).

Mit paccache (Paket pacman-contrib) lässt sich das steuern.

---

Wo liegt der Cache?

Standardpfad ist /var/cache/pacman/pkg. Wird in /etc/pacman.conf kein CacheDir gesetzt, gilt dieser Pfad:

# Konfiguration prüfen
grep -E '^CacheDir' /etc/pacman.conf
# nicht gesetzt → Standard /var/cache/pacman/pkg

# Aktuelle Größe (root-owned, daher sudo nötig)
sudo du -sh /var/cache/pacman/pkg

Achtung: Der Pacman-Cache liegt nicht unter ~/.cache/pacman. Er gehört dem System und braucht sudo. ~/.cache/pacman existiert auf Arch normalerweise nicht.

---

paccache: Optionen

paccache v1.13.1

Operationen (was passieren soll):

Option	Bedeutung
-d, --dryrun	nur Kandidaten finden, nichts löschen
-r, --remove	Kandidaten löschen
-m, --move <dir>	Kandidaten nach <dir> verschieben statt löschen

Optionen (wie ausgewählt wird):

Option	Bedeutung
-k, --keep <num>	nur die <num> neuesten Versionen pro Paket behalten (Default: 3)
-u, --uninstalled	nur Pakete, die derzeit nicht installiert sind
-c, --cachedir <dir>	zu durchsuchendes Verzeichnis (Default: aus /etc/pacman.conf)
--min-atime <zeit>	Pakete behalten, die jünger als <zeit> sind – unabhängig von -k
--min-mtime <zeit>	dito, anhand des Änderungsdatums (zuverlässiger, siehe unten)
-i, --ignore <pkgs>	Paketnamen ausschließen (Komma-separiert)
-v, --verbose	ausführlicher, bis -vvv
-q, --quiet	Ausgabe reduzieren
-f, --force	entspricht rm -f / mv -f
-z, --null	null-Trennzeichen in der Ausgabe (nur mit -v/-vv)
--nocolor	keine Farbformatierung

Achtung, Default: Ohne -k behält paccache 3 Versionen pro Paket. Wer gezielt reduzieren will, muss -k explizit setzen.

Die beiden wichtigsten Aufrufe:

# Vorschau: 2 neueste Versionen behalten
sudo paccache -rk2 -v

# Ausführen
sudo paccache -rk2

Sicherster Testlauf erst verschieben, dann löschen

Statt direkt zu löschen kann man Kandidaten in ein Sammelverzeichnis verschieben und erst nach Prüfung endgültig entfernen:

sudo paccache -m /tmp/pacman-cache-backup -rk2
du -sh /tmp/pacman-cache-backup
# nach Kontrolle:
rm -rf /tmp/pacman-cache-backup

--min-atime vs. --min-mtime

Diese Optionen durchbrechen das -k-Limit: alles, was jung genug ist, bleibt erhalten. Auf einem noatime-Mount ist --min-atime jedoch unzuverlässig, weil Lesezugriffe die Zugriffszeit nicht mehr aktualisieren – dort misst atime faktisch nur den letzten Schreibzugriff. In dem Fall --min-mtime verwenden. Siehe IT-Know-How/Linux/BASH Basics/find.

Gemessene Einsparung (System dieses Nutzers, 66 GB Cache)

Aufruf	Kandidaten	Freier Speicher
paccache -rk2 (2 Versionen behalten)	4332	40,3 GiB
paccache -ruk0 (nur installierte behalten)	99	12,8 GiB
paccache -rk0 (nichts behalten)	7153	65,7 GiB

Empfehlung: -rk2. Es erhält zwei Versionen pro Paket und damit die Möglichkeit, ein Update zurückzunehmen. -rk0 ist maximal gründlich, lässt aber kein Downgrade zu – bei einem defekten Update dann nur noch der Weg über das Archiv.

-duk0 entfernt ausschließlich Pakete, die gar nicht mehr installiert sind – z. B. Rückstände nach pacman -R. Das ist die unkritischste Variante.

Downgrade statt löschen

Solange die .pkg.tar.zst im Cache liegt, funktioniert ein Downgrade direkt:

sudo pacman -U /var/cache/pacman/pkg/paket-1.0.0-1-x86_64.pkg.tar.zst

Genau deshalb ist -k 2 sinnvoller als -k 0.

---

Automatisch aufräumen: paccache.timer

paccache bringt bereits einen Systemd-Timer mit, der auf diesem System vorinstalliert, aber deaktiviert ist:

# Status prüfen
systemctl is-enabled paccache.timer     # → disabled
systemctl list-timers paccache.timer

Einrichtung:

# 1. Timer aktivieren (läuft dann wöchentlich)
sudo systemctl enable --now paccache.timer

# 2. Verhalten festlegen: 2 Versionen behalten
sudo sed -i 's/^PACCACHE_ARGS=.*/PACCACHE_ARGS="-rk2"/' /etc/conf.d/pacman-contrib

# 3. Einmalig sofort ausführen
sudo systemctl start paccache.service

# 4. Nächsten Laufzeitpunkt ansehen
systemctl list-timers paccache.timer

Die Argumente kommen aus der Environment-Datei /etc/conf.d/pacman-contrib:

# Standard: leer
PACCACHE_ARGS=

Wird sie nicht gesetzt, verwendet der Service nur paccache -r (Standardverhalten des Tools). Deshalb lohnt sich das Setzen auf -rk2.

Der Service ist bereits sinnvoll vorkonfiguriert – Type=oneshot, Nice=19, CPUSchedulingPolicy=idle sowie diverse Härtungsoptionen (ProtectSystem=full, ProtectHome=yes, NoNewPrivileges=yes, …). Die Cache-Bereinigung läuft also mit niedrigster Priorität und blockiert keine interaktive Arbeit.

Persistent=true ist im Timer gesetzt: War der Rechner ausgeschaltet, wird die aufgeholte Ausführung beim nächsten Start nachgeholt.

Rhythmus ändern

Standard ist OnCalendar=weekly. Für einen selteneren Durchlauf einen Drop-in anlegen:

sudo systemctl edit paccache.timer

[Timer]
OnCalendar=
OnCalendar=monthly

Die leere OnCalendar= ist wichtig: sie setzt die vorhandene Liste zurück, sonst hätte das System beide Zeitpläne (weekly und monthly) parallel.

Danach:

systemctl cat paccache.timer      # Drop-in prüfen
systemctl list-timers paccache.timer

---

Warum kein Cron?

Für diese Aufgabe ist ein Cronjob die schlechtere Wahl:

1. Root ohne interaktive Passwortabfrage. Der Job bräuchte sudo im Befehl. Ein sudo-Prompt in einer Cron-Umgebung schlägt still fehl – der Job sieht aus, als liefe er, passiert aber nichts. Bei einem User-Cron zusätzlich: Cron läuft ohne volles Terminal, sudo kann die Passwortabfrage oft nicht darstellen.
2. Die systemd-Unit existiert bereits. Sie ist sandboxed, priorisiert und Persistent. Das in Cron nachzubauen hieße, es schlechter zu machen.
3. Ausgabe geht verloren. Bei journalctl -u paccache.service ist nachvollziehbar, was gelöscht wurde – bei Cron nur in Logdateien.

Als Faustregel: Was eine Aufgabe als Root und/oder regelmäßig braucht → systemd-Timer. Was als normaler User und unregelmäßig läuft → Cron oder systemd-run --user.

Für den AUR-Cache ist Automation ohnehin unnötig: yay -Sc räumt ihn auf, und er belegt nur noch ~100 MB. Siehe IT-Know-How/Linux/yay Cache reparieren.

---

Siehe auch

• IT-Know-How/Linux/yay Cache reparieren - AUR-Cache, .git-Korruption durch Cleanup
• IT-Know-How/Linux/Paketinstallation in Linux-Distributionen - pacman/yay Grundbefehle
• IT-Know-How/Linux/BASH Basics/find - sichere -delete-Kommandos für Cache-Aufräumen