weidner/archives/2014/02/

Wann ist die Platte voll?

Auch wenn ich es besser weiß, passieren mir trotzdem simple und doch gravierende Fehler.

Neulich erst entdeckte ich im Log eines Systems Fehlermeldungen, die auf eine volle Platte zu deuten schienen:

System error for fopen: "No space left on device"
...
create file incoming/559266.7205: No space left on device
...
Can't open /var/lib/samba/wins.dat.7208. Error was No space left on device

Angemeldet am System sah mit df alles ganz in Ordnung aus. Die Logdateien wuchsen weiter, also war doch genug Platz da. Oder?

Im ersten Moment hatte ich nicht daran gedacht, auch als ich sah, wie die Logdateien weiter wuchsen, kam ich nicht drauf. Erst als ich eine neue Datei anlegen wollte und nicht konnte, fiel der Groschen. Der Befehl df -i bestätigte mir das Problem: in dem Dateisystem waren keine Inodes mehr verfügbar. Da das System weder Mail- noch News-Server war, kam mir nicht in den Sinn, dass die Inodes ausgehen könnten.

Auf diesem System waren also einige Hunderttausend winzige Dateien, die zwar wenig Platz brauchten, aber jede einen Inode. Die musste ich nur noch finden. Jedes einzelne Verzeichnis mit ls zu inspizieren hat bei mehr als 10000 Verzeichnissen auf dem Rechner keinen Zweck.

Um etwas zu finden, gibt es das Programm find. Nur, wie sag ich diesem, was ich zu finden wünsche.

Das hat jemand anders auch gefragt und auf AskUbuntu eine Antwort bekommen. Wenn ich nach sehr vielen kleinen Dateien suche, dann müssen diese in irgendwelchen Verzeichnissen verlinkt sein. Und je mehr Dateien in einem Verzeichnis verlinkt sind, umso größer wird das Verzeichnis. Ich suche also nach sehr großen Verzeichnissen.

# find / -xdev -type d -size +100k

Die Argumente des Befehls find besagen folgendes: suche in und unterhalb des Verzeichnisses / ohne das Dateisystem zu verlassen (-xdev) nach Verzeichnissen (-type d), deren Größe 100 kByte übersteigt (-size +100k). Bei der Größe musste ich etwas variieren, ab -size +300k blieb nur noch ein Verzeichnis übrig: /var/cfengine/output/.

Auf diesem Rechner lief CFEngine, aber offensichtlich stimmte etwas mit dem Housekeeping nicht. Bei näherer Inspektion stellte ich fest, dass der Rechner früher selbst Test-Policy-Hub für CFEngine war und danach nicht auf den richtigen Policy-Hub umgestellt wurde.

# cf-agent --bootstrap --policy-server $ip_policy_hub

Damit stellte ich den Rechner auf den neuen Hub um und kurze Zeit später holte CFEngine sich die aktuelle Konfiguration und entfernte die alten Dateien in /var/cfengine/output/.

Wer sich mit CFEngine auskennt, wird aus dem obigen Befehl erkennen können, dass da eine ältere Version als 3.5 läuft, weil ab Version 3.5 die IP-Adresse des Policy-Hub Argument der Option --bootstrap ist. Aber das kann man sich auch anhand der großen Anzahl von Dateien ausrechnen, dass cf-agent sehr lange gelaufen sein muss, um mehr als 100000 Dateien zu erzeugen. Normalerweise läuft cf-agent etwa aller fünf Minuten, also 12 mal pro Stunde und 288 mal am Tag. Auf dem Dateisystem sind jetzt wieder mehr als 180000 Inodes verfügbar. Also brauchte der Rechner mehr als 600 Tage um alle Inodes aufzubrauchen. Version 3.5 kam im Juni vergangenen Jahres raus, das ist sehr viel weniger als 600 Tage her.

Update (2022-02-15): Vor ein paar Tagen hatte ich ein ähnliches Problem. Der Trick mit find funktionierte nicht so gut, dafür fand ich eine Möglichkeit, die vielen kleinen Dateien mit du zu finden.

Posted 2014-02-26
Tags: