Trotz gegenteiliger Meldungen des Befehls df steht in verschiedenen Log- Dateien dass die Festplatte voll ist. Es lassen sich keine neuen Dateien anlegen oder geänderte speichern! Vielleicht ist ein "zu volles" Verzeichnis schuld? Doch welches ist es, und wie lösche ich so viele Dateien wenn rm den Dienst verweigert?
Vor einigen Monaten habe ich ein wenig mit dem "nullmailer" experimentiert. Ich habe ihn mit
sudo apt install nullmailerinstalliert, meine Versuche gestartet und ihn anschließend einfach auf dem Server hinterlassen. Das hat er mir wohl übel genommen; er erstellte fleißig etwa 2k große Dateien im Verzeichnis /var/spool/nullmailer/failed - und das etwa 20x pro Minute für ein paar Monate.
In den letzen Tagen konnte keine Datei mehr auf dem Samba share ablegt werden. Ein Abfrage mit df ergab allerdings noch 32% freien Speicherplatz. Trotzdem wurde in diversen Logdateien immer "Disk full" gemeldet. Die Ursachensuche war nicht so einfach. Irgendwann schwante mir jedoch, dass da irgendetwas mit maximalen Dateien pro Verzeichnis war. Je nach Filesystem ist die Anzahl der maximalen Dateien unterschiedlich. Hier hatte ich wohl irgendeine Grenze erreicht...
Die Suche nach dem Verzeichnis mit der größten Anzahl an Dateien erfolgte mit
sudo du -x / | sort -n | tailund spuckte unter anderem das Verzeichnis /var/spool/nullmailer/failed aus. Leider schlug mein Versuch das Verzeichnis mit rm zu leeren fehl. rm quittierte mit einem "The parameter list is too long". Offensichtlich werden hier zuerst alle Dateinamen eingelesen und dann gelöscht. Wegen der hohen Anzahl an Dateien, ist aber der Speicher vollgelaufen und rm endete mit der Fehlermeldung.
Zum Glück fand ich auf der Seite von Marco Gabriel eine Lösung hierfür. Der Befehl find gibt gefundene Dateien einzeln aus und kann diese direkt löschen:
sudo find /var/spool/nullmailer/failed -name "*" -delete -printMit -print kann man die Ausführung verfolgen, ohne geht es ein wenig schneller. Dies dauerte bei mir etwa eine dreiviertel Stunde, und ich hatte ungefähr 15 Gb gelöscht.
Da der nullmailer noch lief, wurden auch fleißig weitere neue Dateien erzeugt. Es waren tatsächlich zwei Mails welche ich bei meinen Tests erzeugt hatte und die weiter im System herumgeisterten. Allerdings hatte ich den nullmailer nur für den internen Gebrauch eingerichtet, so dass er die externe Mailadresse nie erreichen konnte.
Das Verzeichnis /var/spool/nullmailer/queue war leer. Ich sah hier nur kurz eine neu erzeugte Datei, wusste aber nicht warum diese immer weiter erstellt wurde. Da ich keine weitere Zeit für die Ursachenforschung hatte und den nullmailer nicht zwingend brauchte, deinstallierte ich ihn einfach mit
sudo apt remove nullmailer
