Note: yay cache .git root cause, find -prune/-delete gotcha, paccache timer
This commit is contained in:
@@ -0,0 +1,214 @@
|
||||
# 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:
|
||||
|
||||
```bash
|
||||
# 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:
|
||||
|
||||
```bash
|
||||
# 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:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
# Status prüfen
|
||||
systemctl is-enabled paccache.timer # → disabled
|
||||
systemctl list-timers paccache.timer
|
||||
```
|
||||
|
||||
Einrichtung:
|
||||
|
||||
```bash
|
||||
# 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`:
|
||||
|
||||
```bash
|
||||
# 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:
|
||||
|
||||
```bash
|
||||
sudo systemctl edit paccache.timer
|
||||
```
|
||||
|
||||
```ini
|
||||
[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:
|
||||
|
||||
```bash
|
||||
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
|
||||
Reference in New Issue
Block a user