Archeron
Anmeldungsdatum: 9. November 2011
Beiträge: Zähle...
|
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
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4212
|
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.
|
Archeron
(Themenstarter)
Anmeldungsdatum: 9. November 2011
Beiträge: 9
|
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
|
maxritti
Anmeldungsdatum: 18. September 2019
Beiträge: Zähle...
|
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ß
|
Speedy-10
Anmeldungsdatum: 23. März 2010
Beiträge: 835
|
Hi Archeron,
führe doch mal sudo journalctl --vacuum-size 100M aus, dann sollte genug Platz für ncdu frei werden. LG
|
Archeron
(Themenstarter)
Anmeldungsdatum: 9. November 2011
Beiträge: 9
|
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
|
ChickenLipsRfun2eat
Supporter
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12070
|
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“)
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 7478
|
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 😉
|
Archeron
(Themenstarter)
Anmeldungsdatum: 9. November 2011
Beiträge: 9
|
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
|
ChickenLipsRfun2eat
Supporter
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12070
|
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.
|
Archeron
(Themenstarter)
Anmeldungsdatum: 9. November 2011
Beiträge: 9
|
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
|
ChickenLipsRfun2eat
Supporter
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12070
|
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.
|
Archeron
(Themenstarter)
Anmeldungsdatum: 9. November 2011
Beiträge: 9
|
Danke dir für deine zahlreichen Hinweise. Werd mich mal dranmachen und geb dann feedback, sobald ich was herausgefunden habe Gruß Richard
|
maxritti
Anmeldungsdatum: 18. September 2019
Beiträge: 6
|
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
Supporter
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12070
|
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.
|