staging.inyokaproject.org

Hallo Ubuntuusers,

heute morgen habe ich festgestellt, dass mein Server über Nacht meine Systemplatte komplett belegt hat und somit die meissten Dienste aufgrund der vollen Platte nicht mehr richtig oder gar nicht mehr funktionieren.

Es geht um die Platte/Partition:
Disk /dev/nvme0n1: 465,76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 970 EVO Plus 500GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D8500D92-DC33-4D35-9B8F-6D908764AC5B

Device           Start       End   Sectors   Size Type
/dev/nvme0n1p1    2048   2203647   2201600     1G EFI System
/dev/nvme0n1p2 2203648 976771071 974567424 464,7G Linux filesystem

df -h gibt das hier aus:
/dev/nvme0n1p2 457G 445G 0 100% /

prüfe ich alle Verzeichnisse mit "du" auf / durch, komme ich auf max. 150GB Belegung der Platte.

Ich finde nicht einmal die großen Dateien, damit ich Rückschlüsse ziehen könnte. Bin da etwas ratlos gerade.

Dienste habe ich Samba am laufen ansonsten ca 30 Docker Container.

Als System verwende ich Ubuntu Server 22.04.02 LTS, das ganze habe ich vor einem halben Jahr aufgesetzt und bisher lief das alles reibungslos. System ist aktuell

Die HW:
Board: Asus B550-Plus
AMD Ryzen 5 5600G
64GB G.Skill

Der einzige Unterschied zu gestern ist, dass ich heute Nacht ein Update für Crowdsec (Docker) erhalten habe.
Wenn noch mehr Infos benötigt werden, dann Fragen.
Bin über jede Hilfe dankbar.

Gruß Richard

Schau am Besten mal mit ncdu, wo der Platz denn verbraten wird, also

sudo apt install ncdu
sudo ncdu /

Wenn Du dann wirklich nichts findest, was diese Menge an Platz verbraucht, dann wird der Platz von großen Dateien belegt, die eigentlich schon gelöscht sind, wo aber der Filehandle von Programmen noch offen gehalten wird.

Das kannst Du mit folgendem Kommando mal prüfen:

sudo lsof +L1 2>/dev/null| tail -n +2 |sort -k 10,10 | uniq -f 9| awk '{sum +=$7} END {OFMT = "%.0f"; print sum}'

Das gibt Dir den Platz in Byte aus, der von eigentlich gelöschten Dateien belegt wird.

Guten Morgen Doc_Symbiosis,

danke für das schnelle Feedback.

ncdu wollte ich auch schon installieren, aber da die Platte voll ist, erhalte ich die Meldung, dass ich nicht mehr genügend Platz zum Installieren verfüge.

sudo lsof +L1 gibt nichts aus.

Habe testweise ein Docker-Image mit 1,2GB gelöscht, allerdings hat das auch keine Änderung gebracht.
Platte ist immer noch auf Anschlag und lsof +L1 gibt danach auch nichts aus.

Gruß Richard

Guten Morgen,

ich kann dir nicht helfen, frage mich gerade, ob das Zufall ist. Denn ich habe genau das gleiche Problem wie Du.

Mein Ubuntu 22.04.2 ist allerdings erst ein paar Tage alt. Sprich ich habe es Anfang der Woche aufgesetzt. Es dient als Fileserver und eine kleine Perlapplikation läuft für die Heimautomatisierung.

Aufgefallen ist es mir, als ich eben einen CronJob einrichten wollte.

sudo crontab -e
/tmp/crontab.90Pbv7: No space left on device
Creation of temporary crontab file failed - aborting

ncdu lässt sich auch bei mir nicht installieren und sudo lsof +L1

Ich hoffe, es hat noch jemand Tips.

Gruß

Hi Archeron, führe doch mal sudo journalctl --vacuum-size 100M aus, dann sollte genug Platz für ncdu frei werden. LG

Hallo zusammen,

ich hatte heute morgen bereits ein Image mit 1,2gb gelöscht und konnte danach trotzdem nichts installieren.

Problem besteht auch nach dem löschen der Logs.

Gruß Richard

Hallo!

Zeige mal bitte

df -h; df -i
mount
# falls lvm/btrfs verwendet werden bitte entsprechende Ausgaben wie
pvs;vgs;lvs  # für lvm

Falls die Logdateiengrößen rasant ansteigen, solltest du die mit journalctl -f verfolgen. Gefilterte Blicke ins journalctl wären ggf. auch hilfreich (Fehler, Warnungen, bestimmte Units, etc.).

Lesestoff: Festplatten Problembehebung (Abschnitt „Dateisystem-voll“)

Archeron schrieb:

Ich finde nicht einmal die großen Dateien, damit ich Rückschlüsse ziehen könnte. Bin da etwas ratlos gerade.

Wie weit dein Server noch funktionirt, kann ich leider nicht aus deinen Informationen entnehmen.
Vllt hilft dieser Befehl. Systeminformationen ermitteln (Abschnitt „Dateien-Ordner“)

Die 15 größten Dateien insgesamt auflisten:

find / -type f -printf "%k\t %p\n" 2>/dev/null | sort -rn | awk '{printf("%7.1f GiB\t%s\n", ($1/1024)/1024,$0)}' | head -15 

Nachtrag:

kann dauern.(Geduld) 😎
Hinweis: head -15 😉

Hallo,

@Berlin1946: den Befehl kann ich auch nicht ausführen, wieder der selbe Fehler, kein Platz auf der Platte

sort: write failed: /tmp/sortGUCHUt: No space left on device

Im Moment läuft nur noch Samba nativ, alle Container sind gestoppt, da die nicht mehr richtig funktioniert haben, bzw. ich vermeiden wollte, dass mir Daten verloren gehen.
Alle Schreibzugriffe auf die Systemplatte werden abgebrochen mit der Meldung, dass kein Platz mehr vorhanden ist.

@all:

Ich habe mir die Tips zum Dateisystem bereits angeschaut und auch nichts unauffälliges gefunden.

Meine Ausgaben:

df -h
Filesystem             Size  Used Avail Use% Mounted on
tmpfs                  6,3G  3,4M  6,3G   1% /run
/dev/nvme0n1p2         457G  443G     0 100% /
tmpfs                   32G     0   32G   0% /dev/shm
tmpfs                  5,0M  4,0K  5,0M   1% /run/lock
/dev/nvme0n1p1         1,1G  6,1M  1,1G   1% /boot/efi
/dev/sdd1              458G   61G  374G  14% /home
/dev/md0p1              15T  8,6T  6,1T  59% /media/raid
192.168.1.246:/Backup   15T   17G   15T   1% /media/backup
tmpfs                  6,3G  4,0K  6,3G   1% /run/user/1000

df -i
Filesystem                Inodes  IUsed      IFree IUse% Mounted on
tmpfs                    8140890   1131    8139759    1% /run
/dev/nvme0n1p2          30457856 743027   29714829    3% /
tmpfs                    8140890      1    8140889    1% /dev/shm
tmpfs                    8140890      4    8140886    1% /run/lock
/dev/nvme0n1p1                 0      0          0     - /boot/efi
/dev/sdd1               30531584  27513   30504071    1% /home
/dev/md0p1            1562778176 454053 1562324123    1% /media/raid
192.168.1.246:/Backup  480833536   1604  480831932    1% /media/backup
tmpfs                    1628178     25    1628153    1% /run/user/1000

Die Ausgabe der 10 größten Ordner:

sudo du -hsx /* | sort -rh | head -10 
90G     /opt
61G     /home
14G     /var
3,6G    /usr
1,1G    /swap.img
254M    /boot
6,1M    /etc
3,4M    /run
92K     /root
76K     /tmp

Ich war leider zu schnell bei dem Tip von speedy, mir ist auch genau in dem Augenblick, als ich enter gedrückt habe, der Gedanke gekommen, dass ich da eigenntlich hätte reinschauen können 😐 Da ist leider nicht mehr viel zu holen.

Die Größe der Logdateien für das Dateisystem waren bei 2,8gb. Nach der Bereinigung, war ich bei 24mb.

Falls ihr mehr Details benötigt, einfach schreiben.

Vielen Dank im Voraus für eure Unterstützung

Gruß Richard

Ich entnehme mal dem df die mounts: Du musst schon auf / was löschen, nicht in den anderen gemounteten Partitionen. Wenn nach dem Löschen so schnell der Platz wieder weg ist, würde ich auf ein Amokprogramm tippen. Dazu wie geschrieben journalctl -f o.ä. konsultieren. Irgendwas brät ja da den Platz weg. Ebenso mal die timer-units überprüfen, vielleicht läuft da ein Backupprogramm und schaufelt wie verrückt auf die falsche Partition.

Hallo,

ja das ist mir bewusst, dass mir das löschen auf den gemounteten Partionen nicht weiter hilft.

das einzige, was ich gerade dem journalctl entnehmen kann, ist dass in syslog nicht geschrieben werden kann, die unten stehende Meldung kommt alle paar Sekunden.

file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2112.0 try https://www.rsyslog.com/e/2027 ]
action 'action-2-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2112.0 try https://www.rsyslog.com/e/2027 ]

Skripte für Backups habe ich zwar geschrieben, aber derzeit noch nicht automatiert am laufen, daher schließe ich das mal aus.

Mit den timer-units habe ich mich bisher noch nicht beschäftig, ich schau mir das mal an.

Wenn ich da gar nicht weiter komme, dann werd ich wohl neu aufsetzen, aber das möchte ich als letzen Schritt machen. Bin da noch etwas unschlüssig, da maxritti das gleiche Problem mit einem relativ frisch aufgesetztem System hat.

Danke und Grüße
Richard

Na, Baustellen gibt es da viele. crontab bspw. sollte man vermeiden und gleich selbst eine unit anlegen. Das verhindert, das beim automatischen Übersetzen von cron in eine systemd-unit irgendwelche unerwartete Nebenwirkungen auftreten. cron läuft halt nicht unter systemd und wenn man es benutzt, wird einer der vielen generatoren angeschmissen. Wie bei fstab bspw. auch (wobei der sehr gut funktioniert).

Wenn du neu aufsetzt: Nutze LVM o.ä. und lege dir separate Partitionen für /var/log, /var/lib/docker, etc. an. Wenn da dann was Amok läuft, läuft dir nicht / voll, sondern „nur“ eine einzelne Partition.

Du hast auch immense Daten in /opt — wäre auch eine Überlegung wert, je nachdem was da liegt. Das sind ja normalerweise an der Paketverwaltung vorbeigezauberte Sachen.

Eine Neuinstallation würde ich an der Stelle aber gar nicht vorschlagen, sondern den Dienst ausmachen, der vollaufen lässt. Sonst installierst du wieder so und hast das selbe Problem erneut.

Vielleicht hilft es in dem Fall auch mal „von außen“ mit einem Live-Medium nachzusehen oder den Start (siehe systemd target units) vor erreichen des multi-user.target abzubrechen, systemd im Debugmodus zu starten, etc. Möglichkeiten gibt es viele, welche sinnvoll ist ist nicht abzuschätzen, da wir nicht wissen was bei dir alles läuft — und Amok laufen kann.

Danke dir für deine zahlreichen Hinweise.

Werd mich mal dranmachen und geb dann feedback, sobald ich was herausgefunden habe

Gruß
Richard

Ich kann bei mir nun Entwarnung geben. Mein Problem ist gelöst. Es war das 40cm Problem. Also selbstgemacht. 😉

Wie beschrieben habe ich die Ubuntu Installation gemacht. Leider auch alles auf die root Partition und keine separate Partition(en) für /var usw. Dann auf /srv/ ein share erstellt, wo ich ein Verzeichnis für Samba habe, was als Fileserver für meine Frau, Sohn und mich gilt.

Dann die besagte Perl Applikation (FHEM) für die Heimautomatisierung unter /opt erstellt. Die loggt alles nach /opt/fhem/log.

Naja, dann eine externe Platte an USB angeschlossen und des nächtens ein Sync von /srv/ und den FHEM Konfigs auf die externe Platte machen wollen. Dummerweise ist wohl die erste Sicherung nicht auf die unter /media zu mountende Platte gelandet. /media war nicht auf die Platte gemountet. Somit alles auf der internen Platte gelandet. War wohl ein bisschen viel. ☺

Sorry, dass ich dein Posting Richard gekapert habe. Aber es sah alles so gleich aus wie bei Dir. Drücke die Daumen, dass Du es noch gelöst bekommst.

Gruß Max

ChickenLipsRfun2eat schrieb:

…vielleicht läuft da ein Backupprogramm und schaufelt wie verrückt auf die falsche Partition.

Also der Klassiker 😉 Haben wir wohl alle schon mal hinbekommen. Und egal wie viel du löschst, das Backuptool versucht jedesmal brav wieder ein Backup zu erstellen, ist ja keins da.

Ähnliches kann dir auch mit anderen Diensten passieren, wenn du bspw. mit mount --bind Mist baust und dann rekursiv immer wieder das selbe verarbeitest.