Hilfe Partition voll

Seite 1 von 2 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/hilfe-partition-voll_226824/page_1 - zur Vollversion wechseln!

Umlüx schrieb am 19.10.2011 um 10:14

gleich vorweg: ich bin absoluter linux noob

einer unserer XEN server reagiert seit heute früh nicht mehr. die ursache hab ich auch schnell gefunden, da ich gestern genau das gleiche schon einmal hatte..

Code:

[root@xen01 /]# df -h  Filesystem
                              Size  Used Avail Use% Mounted on  
/dev/cciss/c0d0p1     3.8G  3.8G     0 100% /

root ist voll!
den fehler gestern konnte ich mit hilfe der citrix foren noch finden. logfiles aufräumen. danach waren auch wieder knapp 990MB frei.
das ist diesmal aber nicht der grund, denn ich hab heut kaum mehr logfiles als gestern unter /var/log. vielleicht 20mb mehr

also hab ich mich mit hilfe von google und unserm GAT mal auf die suche nach platzfressern gemacht... und keine gefunden..
wenn der zusammengestoppelte befehl
find -xdev -mtime -1
funktioniert, dann haben sich seit gestern genau dateien mit einer gesamtgröße von 95mb geändert.
ich hab mich sogar schon mit du -sh durch die verzeichnisse gehangelt ohne was aufregendes zu finden. langsam bin ich ratlos was ich noch machen könnte..

that schrieb am 19.10.2011 um 10:19

Mit "du" auf die Suche nach Platzfressern gehen.

Aber nicht alle Dateien müssen im Directory stehen - wenn ein Prozess eine Datei offen hat, kann sie aus dem Verzeichnis gelöscht sein, aber immer noch Platz belegen.

COLOSSUS schrieb am 19.10.2011 um 10:36

Wenn die Ausgaben von `du -shx /` und der Usage, die durch `df -h` fuer das FIlesystem angegeben wird, stark auseinandergehen, ist das ein starkes Indiz fuer das von that beschriebene Phaenomen.

Umlüx schrieb am 19.10.2011 um 10:46

"du -shx /" gibt mir den belegten speicherplatz aus?

Code:

[root@xen01 /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p1     3.8G  3.6G   28M 100% /
none                  376M     0  376M   0% /dev/shm
/opt/xensource/packages/iso/XenCenter.iso
                       44M   44M     0 100% /var/xen/xc-install
//nas3.springerreisen.com/software
                       11T  4.9T  5.9T  46% /var/run/sr-mount/23f8b998-e10c-ec2c-9f8b-660488d49ecf
[root@xen01 /]# du -shx /
du: cannot access `/var/run/sr-mount/4b11ab4c-77fe-4ef6-be7d-3fc4626f5690': No such device or address
2.0G    /

2.0GB belegt also, doch die part. ist voll? dann scheint es wohl wirklich darauf hinzudeuten.
was mach ich nun dagegen?

COLOSSUS schrieb am 19.10.2011 um 11:07

Die Inodes, die noch Hardlinks im Dateisystem haben, summieren sich auf 2.0GB. (Das ist die Ausgabe von `du`.)

Dein Filesystem sagt dir, dass es 3.6GB belegt hat. (Das ist die Ausgabe von `df`.)

Ergo: Es ist eine gewisse Anzahl von Prozessen im System, die Filedeskriptoren auf ehemals existente Dateien offen haben, die diesen "Verschnitt" von ~1.6GB verursachen. Welche Datei(nam)en bzw. Prozesse das waren/sind, kannst du bspw. mit lsof herausfinden (probier mal `lsof -X / | grep "(deleted)$"`).

Um den Platz im Dateisystem wieder freizugeben, musst du erreichen, dass alle auf diese Inodes verweisenden Filedeskriptoren durch deren Prozesse geschlossen werden. Im Zweifelsfall bedeutet das, dass diese Prozesse beendet werden muessen. Ein Reboot der Maschine sollte in jedem Fall dafuer sorgen, dass der "verlorene" Platz wieder da ist.

Umlüx schrieb am 19.10.2011 um 11:11

danke für die erklärung.
(und leider: -bash: lsof: command not found)

reboot ist grad schlecht, die maschine ist der master der xen farm.
ich kann die VMs auch nicht verschieben oder runterfahren, da ich mit dem XenCenter gar nicht drauf komme und auch jeder xe- befehl sofort hängenbleibt.

ich hab mal einen case bei unserem retailer eröffnet. aber bis der sich an citrix wendet und wir eine antwort haben dürfte es dauern...

ich hab ausserdem nochmal versucht wenigstens ein bisschen platz zu schaffen, indem ich alte logs lösche. doch der gewonnene platz, es waren um die 60mb, läuft binnen minuten wieder voll.

COLOSSUS schrieb am 19.10.2011 um 11:17

Ah, the joys of commercial support

lsof kannst du ziemlich sicher aus den Repos - solche bietet vermutlich sogar XenServer? - nachinstallieren. Alternativ: http://coloss.us.to/lsof.x86_64 (md5sum: 49a49493658f74353302080161243610)

Umlüx schrieb am 19.10.2011 um 11:21

das geht ziemlich sicher, nur muss ich linuxnoob erst mal nachgoogeln wie man das macht und schnell genug sein bevor die platte wieder voll ist.
wenn ichs hinkriege poste ich die ausgabe dann hier.

Crash Override schrieb am 19.10.2011 um 11:22

Ohne Platz wird aber das installieren schwer....

COLOSSUS schrieb am 19.10.2011 um 11:24

Du musst die von mir verlinkte Binary ja nicht auf das voll belegte Dateisystem packen.

Code:

wget http://coloss.us.to/lsof.x86_64 -O /tmp/lsof
chmod a+x /tmp/lsof
/tmp/lsof

COLOSSUS schrieb am 19.10.2011 um 11:30

Ich hab noch schnell eine Alternative in bash zusammengehackt, ist vermutlich nicht so akkurat wie lsof, kann dir aber evtl. auch einen brauchbaren Hinweis geben:

Code:

cd /proc/; for i in [0-9]*; do for l in $i/fd/*; do readlink -f $l; done; done | grep '(deleted)$'

Umlüx schrieb am 19.10.2011 um 11:37

Zitat von COLOSSUS
Ich hab noch schnell eine Alternative in bash zusammengehackt, ist vermutlich nicht so akkurat wie lsof, kann dir aber evtl. auch einen brauchbaren Hinweis geben:
Code:
cd /proc/; for i in [0-9]*; do for l in $i/fd/*; do readlink -f $l; done; done | grep '(deleted)$'

listet mir jede menge dateien auf. darunter auch die (größeren) logfiles die ich bereits gelöscht hatte.
dabei hatte mir df nach der löschaktion korrekt den freigewordenen platz angezeigt.

COLOSSUS schrieb am 19.10.2011 um 11:42

Und was macht das echte lsof auf deiner Maschine?
(Ich will dir nicht widersprechen, aber im Zweifelsfall glaube ich eher dem Bookkeeping des Kernels, was seiner Prozesse offener fds angeht, als deiner Beobachtung )

Hast du mal versucht, saemtlichen auf der Box laufenden und loggenden Daemonen ein SIGHUP zuzusenden? Allen voran dem syslogd? Welche Logfiles hast du ueberhaupt geloescht?

Umlüx schrieb am 19.10.2011 um 11:50

cannot execute binary file
habs aber genau nach deiner anleitung gemacht.

gelöscht hab ich hauptsächlich einige sehr große /var/log/daemon und /var/log/messages files.
bzw erst wegkopiert, eine logrotation eingerichtet und dann gelöscht.
die wuchsen wegen einer fehlermeldung durch einen xen bug voll und wurden nicht rotiert.

COLOSSUS schrieb am 19.10.2011 um 11:56

Zitat von Umlüx
cannot execute binary file
habs aber genau nach deiner anleitung gemacht.

Da duerfte /tmp mit -o noexec gemountet sein. GIb mir bitte mal den Output von `mount` und `uname -a`.