SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-25

df voll, du nicht: Gelöschte Datei finden

Ihr VPS meldet bei df einen vollen Datenträger, du findet den Platz nicht. Finden Sie gelöschte, noch geöffnete Dateien mit lsof und prüfen Sie weitere Ursachen.

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, August 15, 2026.

Warum df einen vollen Datenträger meldet, du aber etwas anderes anzeigt

df meldet, dass der Datenträger voll ist. du findet den belegten Speicherplatz dagegen nicht, weil ein Prozess weiterhin eine gelöschte Datei geöffnet hält. Beim Löschen einer Datei wird ihr Name aus einem Verzeichnis entfernt. Die Datenblöcke werden erst freigegeben, wenn der letzte offene File Descriptor, der auf diesen Inode zeigt, geschlossen wird. du durchsucht Dateinamen und zählt die Datei deshalb nicht. df fragt das Dateisystem ab, wie viele Blöcke reserviert sind. Daher wird die Datei weiterhin gezählt, obwohl sie keinen Namen mehr hat.

Diese Anleitung reproduziert das Verhalten auf einem einfachen Ubuntu-VPS mit bereits installierten Tools. Sie ermittelt den Prozess über /proc und gibt den Speicherplatz ohne Reboot frei. Anschließend werden weitere Ursachen für dasselbe Symptom behandelt: eine Inode-Tabelle ohne freie Einträge, Dateien unterhalb eines Mountpoints und für root reservierte Blöcke.

Führen Sie jeden Befehl aus und prüfen Sie Ihre eigene Ausgabe. Die Werte hängen von Ihrem Datenträger ab. Vergleichen Sie daher die Werte vor und nach der Änderung auf Ihrem eigenen System. Vergleichen Sie sie nicht mit einem Wert, der in einer Anleitung angegeben ist.

Was df zählt und was du zählt

df (disk free) fragt jedes eingehängte Dateisystem nach seiner eigenen Bilanz: wie viele Blöcke vorhanden, wie viele belegt und wie viele frei sind. Es öffnet kein Verzeichnis. Die Antwort umfasst jeden belegten Block, auch Blöcke, die zu einer Datei gehören, auf die kein Verzeichniseintrag verweist.

du (disk usage) arbeitet umgekehrt. Es beginnt bei einem von Ihnen angegebenen Pfad, liest Verzeichnisse, ermittelt die Attribute jedes gefundenen Eintrags und addiert die Blöcke. Eine Datei ohne Namen ist für das Programm unsichtbar. Dasselbe gilt für jedes Verzeichnis, das es nicht lesen darf. Deshalb erhält ein normaler Benutzer eine kleinere Summe als root. Führen Sie du unter sudo aus, bevor Sie aus dem Vergleich Schlussfolgerungen ziehen.

Beim Vergleich der beiden Befehle sind jedes Mal zwei Optionen wichtig.

  • -x beschränkt du auf ein Dateisystem. Ohne diese Option durchläuft du / jedes Dateisystem, das unterhalb von / eingehängt ist, und erzeugt eine Summe, die df / nie erfasst hat.
  • -s gibt pro Argument eine Zusammenfassungszeile statt einer Zeile pro Verzeichnis aus.

Damit ergibt sich das Befehlsduo, das Sie auf dem relevanten Dateisystem nebeneinander ausführen sollten.

df -h /
sudo du -xhs / 2>/dev/null

df liefert sofort eine Antwort. du benötigt auf einem großen Dateisystem mehrere Minuten, weil es auf dem Weg die Attribute jeder Datei ermittelt. Wenn die beiden Summen stark voneinander abweichen und du mit root-Rechten und -x ausgeführt wurde, ist der fehlende Speicherplatz etwas zugewiesen, das keinen Namen hat.

Die Abweichung absichtlich reproduzieren

Führen Sie dies auf einem Test-VPS aus. Alles Folgende verwendet bash und coreutils. Es wird nichts installiert.

Erfassen Sie den Ausgangszustand des Dateisystems, auf dem sich /var/tmp befindet.

cd /var/tmp
df -h .
df --output=used -B1 .

Der zweite Befehl gibt die belegten Bytes ohne Rundung aus. Dadurch ist die Prüfung am Ende exakt.

Erstellen Sie jetzt eine Datei. Ihre Größe ergibt sich aus dem freien Speicherplatz, den das System selbst meldet. Die Demonstration passt daher zu jedem verfügbaren Datenträger.

free=$(df --output=avail -B1 . | tail -n 1)
fallocate -l $((free / 10)) ghost.bin
ls -l ghost.bin
df -h .

$(...) ist eine Befehlsauswertung: Die Shell führt den darin enthaltenen Befehl aus. Die Ausgabe wird zum Wert von free. Wenn diese Syntax für Sie neu ist, erklärt die Befehlsauswertung in bash sie ausführlich. fallocate reserviert reale Blöcke, ohne Daten zu schreiben. Deshalb wird der Befehl sofort beendet. Auf einem Dateisystem ohne Unterstützung dafür schlägt der Befehl fehl. head -c $((free / 10)) /dev/zero > ghost.bin erfüllt dann dieselbe Aufgabe, indem die Bytes geschrieben werden.

Vergleichen Sie dieses df -h . mit dem zuvor erfassten Wert. Die Spalte für die belegten Bytes ist gestiegen. Die Spalte für den verfügbaren Speicherplatz ist gesunken.

Halten Sie die Datei nun von einem anderen Prozess geöffnet. Löschen Sie sie anschließend.

sleep infinity < ghost.bin &
holder=$!
rm ghost.bin
ls -l ghost.bin
df -h .
sudo du -xhs . 2>/dev/null

Die Umleitung ist der entscheidende Teil. sleep infinity < ghost.bin & startet einen Hintergrundprozess, dessen Standardeingabe diese Datei ist. Die Shell öffnet die Datei und übergibt den Dateideskriptor an sleep, das ihn geöffnet hält. $! enthält die Prozess-ID dieses Hintergrundprozesses. rm entfernt anschließend den Dateinamen, während der Dateideskriptor noch geöffnet ist.

Lesen Sie die Ausgabe. ls kann die Datei nicht finden, weil der Dateiname nicht mehr vorhanden ist. du liegt wieder nahe am Ausgangswert, weil dieser Befehl Dateinamen durchsucht. df hat sich nicht verändert, weil die Blöcke weiterhin belegt sind. Das Dateisystem und der Verzeichnisbaum stimmen nun nicht mehr überein. Die Differenz zwischen beiden entspricht der gerade gelöschten Datei.

Prozess ermitteln, der die gelöschte Datei geöffnet hält

Jeder offene Dateideskriptor erscheint unter /proc/<pid>/fd/ als symbolischer Link auf die Datei, auf die er verweist. Wurde die Datei entlinkt, markiert der Kernel das Ziel dieses Links als gelöscht. Den Prozess zu ermitteln bedeutet daher, einen Link zu finden, dessen Ziel diese Markierung trägt.

sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

-lname vergleicht das Ziel eines symbolischen Links und nicht dessen Namen, %p gibt den Pfad zum Deskriptor aus, und %l zeigt, worauf er verweist. Die Prozess-ID ist das zweite Element des ausgegebenen Pfads. Führen Sie den Befehl mit sudo aus, weil Sie andernfalls nur /proc/<pid>/fd für Ihre eigenen Prozesse lesen können. Die Umleitung von stderr unterdrückt Meldungen von Prozessen, die beendet werden, während find das Dateisystem durchsucht.

Ein ausgelasteter Server hält jederzeit mehrere gelöschte Dateien geöffnet. Die meisten davon sind klein und unkritisch. Sortieren Sie sie nach Größe, damit nur die relevanten Dateien oben stehen.

sudo bash -c 'for fd in /proc/[0-9]*/fd/*; do
  target=$(readlink "$fd" 2>/dev/null) || continue
  case "$target" in
    *"(deleted)") echo "$(stat -Lc %s "$fd" 2>/dev/null) $fd $target" ;;
  esac
done' | sort -rn | head

stat -L folgt dem Link bis zum Inode selbst. Dadurch meldet %s die Größe der Datei, die keinen Namen mehr besitzt. Die Sortierung nach dieser Zahl stellt die größte Datei an die erste Stelle.

Ermitteln Sie anschließend den Prozess hinter dem führenden Deskriptor. Der oberste Pfad dieser Liste enthält beide benötigten Zahlen. Speichern Sie sie daher zunächst in Variablen. Ersetzen Sie PID und N durch die Werte aus Ihrer eigenen Ausgabe.

pid=PID
n=N
ps -o pid,user,etime,args -p "$pid"
sudo stat -L "/proc/$pid/fd/$n"

ps gibt den Programmnamen aus und zeigt, wie lange es bereits läuft. stat -L gibt die Größe und die Anzahl der belegten Blöcke des gelöschten Inodes aus. Zusammen beantworten diese Angaben die entscheidende Frage: Welcher Dienst hält diese Datei geöffnet?

Wenn auf dem System bereits lsof vorhanden ist, listet sudo lsof +L1 geöffnete Dateien auf, deren Link-Anzahl auf null gesunken ist, und zeigt die Größen in einer Tabelle. Auf einem minimalen Ubuntu-Image ist das Programm nicht vorhanden. Die Installation eines Pakets kann auf einem Dateisystem ohne freien Speicherplatz selbst fehlschlagen. Deshalb ist der /proc-Durchlauf die Variante, die immer funktioniert.

Speicherplatz ohne Reboot freigeben

Ein Reboot behebt das Problem zwar, ist aber der falsche erste Schritt: Der Dienst wird beendet und die Beweise gehen verloren. Es gibt vier schonendere Optionen. Probieren Sie sie in dieser Reihenfolge aus.

Kopieren Sie die Daten zuerst an einen anderen Ort, wenn Sie sie noch benötigen. Das Lesen des Descriptor-Pfads liest den aktiven Inode.

sudo cp /proc/<pid>/fd/<n> /root/recovered.log

Dies ist der eine Fall, in dem sich eine gelöschte Datei einfach wiederherstellen lässt. Deshalb beginnt Dateien wiederherstellen, die mit rm -rf gelöscht wurden mit der Frage, ob ein Prozess die Datei noch geöffnet hält. Sobald der letzte Descriptor geschlossen wird, ist dieser Weg nicht mehr möglich.

Leeren Sie die Datei als Nächstes über den Descriptor. Der Pfad /proc verweist auf denselben Inode. Durch das Kürzen werden die Blöcke freigegeben, während der Prozess weiterläuft.

sudo truncate -s 0 "/proc/$pid/fd/$n"
df -h /

Das funktioniert zuverlässig, wenn der Writer die Datei im Append-Modus geöffnet hat, weil jeder Schreibvorgang dann an das aktuelle Dateiende geht. Andernfalls behält der Prozess seinen alten Schreiboffset. Der nächste Schreibvorgang landet dann weit hinter dem Dateianfang und erzeugt die Datei mit einem Hole am Anfang erneut. Ein Hole wird nicht reserviert. Die Blöcke bleiben daher frei, und df behält den Speicherplatz, den es gerade freigegeben hat. Nur die Größe wird wiederhergestellt: Führen Sie sudo stat -L "/proc/$pid/fd/$n" erneut aus, nachdem der Prozess geschrieben hat. Der Befehl meldet dann die alte Größe neben einer Blockanzahl, die nicht mehr dazu passt. Starten Sie den Prozess neu, wenn auch die Größe wieder bei null beginnen soll.

Bitten Sie den Dienst als Nächstes, seine Logs erneut zu öffnen. Ein Daemon, dessen Log-Datei unter ihm gelöscht wurde, ist die häufigste praktische Variante dieses Problems. Viele Daemons öffnen ihre Log-Dateien bei einem Signal erneut: nginx verwendet SIGUSR1, rsyslog verwendet SIGHUP. Lesen Sie die Dokumentation des jeweiligen Daemons, statt zu raten. Das falsche Signal an den falschen Daemon beendet ihn.

sudo systemctl kill -s USR1 nginx

Damit wird das Signal an den Prozess gesendet, den systemd als Hauptprozess der Unit erfasst. Eine Unit, die den falschen Type= für den tatsächlichen Start des Daemons angibt, kann Ihr Signal daher an einen Prozess senden, der die gelöschte Datei nie geöffnet hatte. Der Speicherplatz bleibt dann weiterhin belegt.

Starten Sie die Unit zuletzt neu. sudo systemctl restart <unit> schließt jeden Descriptor, den der alte Prozess geöffnet hatte. Dadurch werden die Blöcke sicher freigegeben. In der obigen Demonstration ist der Holder ein sleep, den Sie selbst gestartet haben. Es reicht daher, ihn zu beenden.

kill $holder
df -h .
df --output=used -B1 .
sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

Vergleichen Sie die belegten Bytes mit dem Wert, den Sie vor dem Erstellen der Datei notiert haben. Die Werte stimmen wieder überein, und find meldet Ihren Descriptor nicht mehr. Prüfen Sie das Problem mit demselben Befehl erneut, mit dem Sie es gefunden haben. Diese Gewohnheit ist nützlich.

Es ist einfacher, diese Änderung zu beobachten, als df immer wieder manuell auszuführen. watch wiederholt einen Befehl in einem festen Intervall und gibt die Ausgabe an derselben Stelle erneut aus. Dadurch zeigt watch df -h /, wie sich die Spalte für den belegten Speicherplatz ändert, während der Speicherplatz zurückkommt.

Wenn die Summen übereinstimmen und der Datenträger trotzdem voll ist

Wenn df und ein root-du -x miteinander übereinstimmen, ist keine gelöschte Datei beteiligt. Die verbleibenden Ursachen sind anderer Art und erfordern jeweils eine eigene Prüfung.

Nicht Inodes, sondern Blocks erschöpft

Ein Inode enthält die Metadaten einer Datei. ext4 erstellt beim Anlegen des Dateisystems eine feste Anzahl von Inodes. Deshalb können einem Dateisystem die Inodes ausgehen, obwohl noch freie Blocks vorhanden sind. Neue Dateien lassen sich dann nicht anlegen, obwohl df -h noch freien Speicherplatz anzeigt.

df -h /
df -i /

Der erste Befehl zählt Blocks, der zweite Inodes. Vergleichen Sie jeweils die Spalte use. Eine geringe Block-Auslastung bei maximaler Inode-Auslastung bedeutet, dass sehr viele sehr kleine Dateien vorhanden sind.

df lehnt -i und --output im selben Aufruf ab. Wenn Sie die Rohwerte auslesen oder an einen anderen Befehl übergeben möchten, wählen Sie die Inode-Felder daher anhand ihres Namens aus und lassen Sie -i weg.

df --output=itotal,iused,iavail,ipcent /

Diese Spalten enthalten dieselben Zählwerte, die df -i ausgibt, jedoch in einer Form, die Sie weiterverarbeiten können.

Finden Sie die Dateien, indem Sie die Einträge statt ihrer Byte-Größe zählen.

sudo du --inodes -x -d 1 / 2>/dev/null | sort -rn | head

Führen Sie denselben Befehl eine Verzeichnisebene tiefer in dem Verzeichnis aus, das den höchsten Wert aufweist. Wiederholen Sie dies, bis Sie den Verzeichnisbaum erreichen, in dem die Dateien erstellt werden. Wenn Ihr du --inodes nicht unterstützt, zählt sudo find /var -xdev -type f | wc -l einen Teilbaum auf langsamere Weise.

Die Lösung besteht darin, diese Dateien zu löschen oder zu verschieben. Sie können einem vorhandenen ext4-Dateisystem keine Inodes hinzufügen, weil die Anzahl zum Zeitpunkt mkfs festgelegt wird. Eine Erhöhung der Anzahl erfordert daher, das Dateisystem neu zu erstellen und aus einem Backup wiederherzustellen. XFS weist Inodes bei Bedarf zu und erreicht deshalb nicht auf dieselbe Weise eine feste Obergrenze. Ein Rechner, auf dem Container ausgeführt werden, erreicht beide Grenzen früher als die meisten anderen Systeme, weil Image-Layer viele kleine Dateien enthalten. Auf diesem Rechner ist Docker-Speicherplatz auf einem VPS bereinigen die konkrete Lösung. Dabei wird wesentlich mehr Speicherplatz freigegeben als durch eine allgemeine Suche im Dateisystem.

Unter einem Mountpoint verborgener Speicher

Ein Verzeichnis kann Dateien enthalten, bevor dort etwas eingehängt wird. Hängen Sie ein Dateisystem über diesem Verzeichnis ein, bleiben die darunterliegenden Dateien genau dort: Sie belegen weiterhin Speicherplatz, werden weiterhin von df gezählt und sind nicht mehr über ihren Namen erreichbar. du kann sie nicht sehen, weil der Mount sie verdeckt.

Zeigen Sie dies mit tmpfs, das keinen zusätzlichen Festplattenspeicher benötigt. Für diesen Teil benötigen Sie eine Maschine, auf der Sie Mounts durchführen dürfen. Dies funktioniert daher auf einem KVM-VPS.

sudo mkdir -p /srv/covered
sudo cp /etc/services /srv/covered/
ls /srv/covered
sudo mount -t tmpfs tmpfs /srv/covered
ls /srv/covered
sudo umount /srv/covered
ls /srv/covered

Das mittlere ls zeigt ein leeres Verzeichnis. Die Kopie wurde nicht verschoben. Sie befindet sich weiterhin im Root-Dateisystem und wird wieder sichtbar, sobald Sie den Mount aushängen. Stellen Sie sich nun einen Dienst vor, der einen Monat lang in diesen Pfad geschrieben hat, bevor jemand ein Volume darüber eingehängt hat.

Um das tatsächlich belegte Verzeichnis auf einem laufenden Server zu finden, hängen Sie das Root-Dateisystem an einer zweiten Stelle erneut ein. Ein Bind-Mount zeigt ein Dateisystem, ohne die darin eingehängten Dateisysteme einzubeziehen.

sudo mkdir -p /mnt/rootcheck
sudo mount --bind / /mnt/rootcheck
sudo du -xhs /mnt/rootcheck/* 2>/dev/null | sort -h
sudo umount /mnt/rootcheck

Alles, was in dieser Auflistung erscheint, aber nicht unter dem normalen Pfad, liegt unter einem Mountpoint verborgen. Hängen Sie den Bind-Mount anschließend wieder aus. Andernfalls zählt ein später ausgeführtes du ohne -x dieselben Dateien doppelt.

Für root reservierte Blöcke

ext4 reserviert einen Teil seiner Blöcke für den Benutzer root. Dadurch kann sich root auch bei einer vollständig belegten Festplatte noch anmelden und das System reparieren. Ein Prozess unter einem normalen Benutzer stößt zuerst an diese Grenze, während df weiterhin etwas freien Speicher anzeigt. Lesen Sie die Einstellung auf Ihrem eigenen Dateisystem aus, statt den Standardwert anzunehmen.

dev=$(df --output=source / | tail -n 1)
sudo tune2fs -l "$dev" | grep -i 'block count'

Der Befehl gibt die Gesamtzahl der Blöcke und die Anzahl der reservierten Blöcke in denselben Einheiten aus. Das Verhältnis zwischen beiden lässt sich daher direkt berechnen. df gibt in der Spalte für verfügbaren Speicher den Platz an, den ein normaler Benutzer noch verwenden darf. Deshalb ergibt die Summe aus belegtem und verfügbarem Speicher einen kleineren Wert als die Größe des Dateisystems. Die Differenz ist der reservierte Bereich.

Ändern Sie den Wert mit sudo tune2fs -m <percent> "$dev". Die Änderung wird sofort wirksam und erfordert keinen erneuten Mount-Vorgang. Auf einem separaten Daten-Dateisystem ist es sinnvoll, den reservierten Anteil zu verringern. Auf dem Root-Dateisystem sollten Sie ausreichend Platz reservieren, damit root weiterhin schreiben kann. Ein Root-Dateisystem ohne jeglichen freien Speicher ist wesentlich schwieriger zu reparieren. Der reservierte Bereich verhindert außerdem, dass Sie sich aussperren: Ein an authorized_keys angehängter Schlüssel kann auf einem vollständig belegten Dateisystem nur unvollständig oder gar nicht geschrieben werden. Beim nächsten Login erscheint dann aus einem Grund, der nichts mit dem Schlüssel selbst zu tun hat, Zugriff verweigert (publickey). tune2fs funktioniert mit ext2, ext3 und ext4. Für XFS gibt es keine entsprechende Einstellung.

Wo dich du allein in die Irre führt

Vier Eigenschaften von du führen zu Summen, die falsch aussehen.

  • Hardlinks: du zählt einen Inode nur einmal, selbst wenn mehrere Namen auf ihn verweisen. Daher meldet ein Verzeichnisbaum voller Hardlinks weniger als die Summe seiner Dateien.
  • Sparse-Dateien: du meldet die tatsächlich zugewiesenen Blöcke, während ls -l die scheinbare Größe meldet. Fügen Sie --apparent-size hinzu, um den jeweils anderen Wert anzuzeigen.
  • Berechtigungen: Wenn Sie den Befehl als normaler Benutzer ausführen, überspringt du nicht lesbare Dateien und unterschätzt den Wert. Die ausgegebenen Fehler sind genau die Meldungen, die viele nach /dev/null umleiten und anschließend nicht mehr beachten.
  • Dateisystemgrenzen: Ohne -x zählt du / jedes Dateisystem, das unterhalb von / eingehängt ist. Daher kann die Summe höher sein als der von df / gemeldete Wert.

df hat ebenfalls eine wichtige Eigenschaft. Es meldet jedes Dateisystem separat. Führen Sie den Befehl daher für den genauen Pfad aus, in den der fehlgeschlagene Schreibvorgang schreiben soll. Ein separates /boot füllt sich nach einem eigenen Zeitplan, während sich Kernel-Pakete ansammeln. Alte Kernel unter Ubuntu entfernen ist eine andere Aufgabe als Speicherplatz auf / freizugeben.

Ein sinnvoller Ablauf für einen echten Vorfall

  1. Führen Sie df -h <path> und df -i <path> auf dem Dateisystem aus, auf das der fehlgeschlagene Schreibvorgang zielte, und nicht reflexartig auf /.
  2. Führen Sie sudo du -xh -d 1 <mountpoint> 2>/dev/null | sort -h aus und wechseln Sie anschließend in das größte Verzeichnis.
  3. Wenn du nicht erklären kann, warum df den belegten Speicherplatz meldet, suchen Sie mit /proc nach gelöschten Dateien, die noch geöffnet sind.
  4. Wenn beide Werte übereinstimmen, binden Sie das Dateisystem an einer anderen Stelle ein und suchen Sie nach Dateien unter einem Mountpoint.
  5. Wenn die Inode-Nutzung das Limit erreicht, zählen Sie Dateien statt Bytes.

Jeder Schritt verwendet dabei ein Kommando, dessen Ausgabe Sie lesen können. Das ist der Unterschied zwischen einer gezielten Behebung und bloßem Raten.

FAQ

Warum zeigt df den Datenträger als voll an, wenn du deutlich weniger findet?

Der häufigste Grund ist eine Datei, die gelöscht wurde, während ein Prozess sie noch geöffnet hatte. Durch das Löschen wird der Verzeichniseintrag entfernt, sodass du keinen Namen mehr zum Durchlaufen hat und die Datei nicht weiter mitzählt. Der Inode und seine Blöcke bleiben belegt, bis der letzte Deskriptor geschlossen wird, während df die belegten Blöcke zählt. Durchsuche /proc/<pid>/fd nach symbolischen Links, deren Ziel als gelöscht markiert ist. Dann sehen Sie sowohl die Datei als auch den Prozess, der sie geöffnet hält. Bevor Sie dem Vergleich vertrauen, prüfen Sie, ob Sie du als root und mit -x ausgeführt haben. Ein normaler Benutzer überspringt Verzeichnisse, die er nicht lesen darf, stillschweigend.

Wie finde ich eine gelöschte Datei, die noch geöffnet ist, ohne lsof?

Verwenden Sie die eigene Aufzeichnung des Kernels über geöffnete Deskriptoren. sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null listet jeden Deskriptor auf, der auf eine Datei ohne Namen zeigt. Die Prozess-ID steht dabei im ausgegebenen Pfad. sudo stat -Lc %s auf einem dieser Deskriptorpfade gibt seine Größe aus. Sie können die Ergebnisse daher sortieren und den relevanten Eintrag auswählen. Dafür ist kein Paket erforderlich. Das ist wichtig, weil die Installation eines Pakets auf einem Dateisystem ohne freien Speicherplatz fehlschlagen kann.

Kann ich den Speicherplatz freigeben, ohne den Prozess zu beenden?

Manchmal. sudo truncate -s 0 /proc/<pid>/fd/<n> erreicht über den Deskriptor denselben Inode und gibt dessen Blöcke frei, während der Prozess weiterläuft. Das ist am saubersten, wenn der Prozess die Datei im Append-Modus geöffnet hat, weil seine Schreibvorgänge immer an das aktuelle Ende gehen. Andernfalls bleibt der Schreiboffset an seiner bisherigen Position. Der nächste Schreibvorgang erstellt die Datei dann mit einem Loch am Anfang neu. Dadurch springt die gemeldete Größe wieder an, während die Blöcke unter dem Loch frei bleiben. Ein Neustart der Unit oder ein Signal zum erneuten Öffnen der Logs mit dem in der Dokumentation genannten Signal behebt das Problem, ohne eine Sparse-Datei zurückzulassen.

df zeigt freien Speicherplatz an, aber Schreibvorgänge schlagen weiterhin fehl. Woran kann es noch liegen?

Prüfen Sie die Inodes mit df -i auf demselben Pfad. Ein Dateisystem mit freien Blöcken, aber ohne freie Inodes weist neue Dateien zurück. Prüfen Sie, ob der Schreibvorgang als Benutzer ohne root-Rechte auf einem ext4-Dateisystem ausgeführt wird, auf dem nur noch reservierte Blöcke verfügbar sind. sudo tune2fs -l auf dem Gerät zeigt dies an. Prüfen Sie außerdem, ob Sie das Dateisystem auslesen, auf das der Schreibvorgang tatsächlich zugreift. Ein separates /boot oder /var kann unabhängig von / voll laufen.

Warum meldet du eine größere Gesamtsumme als df?

du ohne -x wechselt in jedes Dateisystem, das unter dem angegebenen Pfad eingehängt ist. Dadurch addiert es mehrere Dateisysteme, während df nur eines beschreibt. Bind-Mounts verschärfen das Problem, weil dieselben Dateien unter jedem Pfad, an dem sie erscheinen, erneut gezählt werden. Fügen Sie -x hinzu, damit du auf ein einzelnes Dateisystem beschränkt bleibt. Übergeben Sie df denselben Pfad, damit beide Befehle dasselbe beschreiben.