root füllt sich automatisch

[cotwild]

guten tag,

nach stundenlangem durchforsten meines system und etliche nachfragen bei linuxnutzern und auch nach einer suche wende ich mich an euch.

mein server (webserver, fileserver, streamingdienst, etc.) warf plötzlich fehlermeldungen von sich, da / zu 100% voll war.
anfangs habe ich noch ein 2.8GB logfile gefunden, das auf grund fehlender bilder auf meiner homepage sich gefüllt hatte. die bilder wurden dann als leerdateien erstellt und nun bleibt das logfile klein.
doch ich habe keine ahnung, WO und WIESO sich der server nun weiter selber füllt. (war in ca. 3-4 tagen voll..)

server:/# df

Code: Alles auswählen

Dateisystem          1K-Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
[b]/dev/hda3              4435468   4211608         0 100% / [/b]
tmpfs                   322620         0    322620   0% /dev/shm
/dev/hda1                30075      5654     22817  20% /boot
/dev/hdb1            192292124  97215108  85309096  54% /data
/dev/hda4              3960976    624232   3135532  17% /usr
/dev/hdc1            192292124 180441428   2082776  99% /mnt/hd2

bei /mnt/hd2 weiss ich, wieso sie voll ist dies ist nicht das problem.

wenn ich mit du -sh * auf / suche, fehlen mir irgendwie 2GB auf / ???
(partition hda3 ist 4,4GB, doch die summe der ordnergrössen ist knapp 2GB und mit ls -l auf / zeigt es keine grosse datei auf / selber... wo ist der platz?? *sniff*

server:/# du -sh *

Code: Alles auswählen

3.2M    bin
5.6M    boot
0       cdrom
93G     data     //auf anderer hardisk /dev/hdb1
96K     dev
5.7M    etc
480M    home
4.0K    initrd
0       initrd.img
38M     lib
48K     lost+found
12K     media
du: Zugriff auf »mnt/audi« nicht möglich: Eingabe-/Ausgabefehler     //netzwerklaufwerk im auto :-)
173G    mnt      //andere hd /dev/hdc1
4.0K    nohup.out
161M    opt
643M    proc
2.1M    root
3.3M    sbin
4.0K    srv
4.0K    sys
36K     tmp
610M    usr     //ebenfalls andere partition, gleiche hd /dev/hda4
284M    var
0       vmlinuz

summe
home 480mb + lib 40mb + opt 160mb + proc 640mb + var 280mb + andere kleine ca. 50mb = 1650mb
und auf / selber hat es gerade mal 153K

server:/# ls -ghS
insgesamt 153K

Code: Alles auswählen

drwxr-xr-x   2 root   48K 2005-06-09 17:38 lost+found
drwxr-xr-x  11 root   24K 2007-07-02 13:26 dev
drwxrwxrwt   4 root   16K 2007-07-21 13:33 tmp
drwxr-xr-x   2 root  4.0K 2006-06-17 21:09 bin
drwxr-xr-x  12 root  4.0K 2007-05-27 10:31 data
drwxr-xr-x  84 root  4.0K 2007-07-20 14:45 etc
drwxrwsr-x   4 staff 4.0K 2005-06-21 15:56 home
drwxr-xr-x   2 root  4.0K 2007-05-27 11:51 initrd
drwxr-xr-x  10 root  4.0K 2007-05-27 23:26 lib
drwxr-xr-x   4 root  4.0K 2005-06-09 17:41 media
drwxr-xr-x   7 root  4.0K 2007-05-22 16:13 mnt
drwxr-xr-x   3 root  4.0K 2005-06-21 09:28 opt
drwxr-xr-x   6 root  4.0K 2005-07-08 10:31 root
drwxr-xr-x   2 root  4.0K 2007-05-27 11:50 sbin
drwxr-xr-x   2 root  4.0K 2005-06-09 17:46 srv
drwxr-xr-x   2 root  4.0K 2005-05-10 22:01 sys
drwxr-xr-x  19 root  4.0K 2007-05-27 10:31 usr
drwxr-xr-x  14 root  4.0K 2005-06-09 17:10 var
drwxr-xr-x   4 root  1.0K 2006-06-17 21:13 boot
lrwxrwxrwx   1 root    27 2005-06-09 17:50 initrd.img -> boot/initrd.img-2.4.27-2-k7
lrwxrwxrwx   1 root    24 2005-06-09 17:50 vmlinuz -> boot/vmlinuz-2.4.27-2-k7
lrwxrwxrwx   1 root    11 2005-06-09 17:41 cdrom -> media/cdrom
-rw-------   1 root     5 2005-07-08 10:00 nohup.out
dr-xr-xr-x  96 root     0 2007-07-02 15:25 proc

wo bleiben die restlichen 2,7GB???

ich habe zudem noch chkrootkit und rkhunter laufen lassen, beide fanden keine rootkits...

für lösungsansätze wäre ich sehr sehr dankbar!! vielen dank im voraus
dave

[mcdikki]

Welches fs hast du drauf?

Bedenke das jedes Journaling fs auch platz braucht zum verwalten des Platzes.
Auch nicht Journaling Fs brauchen platz für die FAT etc.

Ausserdem wäre die Blockgröße noch zu bedenken.

EIne Datei verbraucht mehr platz als sie eigentlich groß ist. Das leigt dran das der SPeicherpaltz der Festplatte nicht in 1 Bit Blchen, sonder oft 64 Kb blöcken verwaltet wird. Wenn eine date nur etwa 65 Kb groß ist braucht sie zwei blöcke = 128 kb.

Vielleicht hilgt es dir die blockgröße deiner Partition mal auf 32 oder 16 zu setzten. Dadurch wird der zugriff zwar langsammer, ist aber beim / nicht so wichtig, die Datenbewegungen finden ja auf anderen Partitionen statt.


Ansonsten vielleicht mal das fs checken, vielleicht ist ja ein fehler drin.


PS: Herzlich Wilkommen im Debianforum!

[Teddybear]

Moin

In der Regel werden 5% der Platte für den root USER reserviert, damit er im fallm eines Falles noch zugriff auf das system bekommen kann.

Greetz Sascha

[AK-Palme]

Hi,
gibt es die Möglichkeit mal im Rescuesystem zu booten und von dort die Grössen anzuzeigen?

Ansonsten mache ich bei komischen plattenlöchern einen kleinen cronjob in der richtung von
10 * * * * root du -h > /root/du/`date`

um zu gucken was da wächst..

[finupsen]

Das leigt dran das der SPeicherpaltz der Festplatte nicht in 1 Bit Blchen, sonder oft 64 Kb blöcken verwaltet wird.

stimmt das ?

Von XFS weiss ich, das die blocksize über 4K sein kann, allerdings nicht mit einem linux-kernel ...
Hat sich da was geändert ?

nachtrag:

man mkfs.ext3

-b block-size
Specify the size of blocks in bytes. Valid block size vales are 1024, 2048 and 4096 bytes per block.

[mcdikki]

Bei XFS weiß ich es nicht sicher. Aber normalerweise wird kein Dateisystem, egal ob Linixkernel oder nicht, mit beliebig kleinen Blocken arbeiten. Das würde ja den aufwand zur verwaltung ins unendliche wachsen lassen.

Aber Profi bin ich da nicht.

[mauser]

Moin

In der Regel werden 5% der Platte für den root USER reserviert, damit er im fallm eines Falles noch zugriff auf das system bekommen kann.

Greetz Sascha

Hey,

wie (durch welche Programme) passiert denn das ??
Gruss,
mauser

[armin]

Das passiert zum Beispiel direkt beim mkfs.ext3 Aufruf.

-m reserved-blocks-percentage
Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and
allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged pro‐
cesses are prevented from writing to the filesystem. The default percentage is 5%.

[novalix]

Mmmh ..

643 MB in /proc
Die sind hoffentlich virtuell?

ciao, niels

[gms]

abgesehen von dem für Root reservieren Speicherbereich, der allerdings extrem groß gesetzt sein müßte, gibt es auch noch andere Möglichkeiten:
vielleicht befinden sich unter den Mountpoints noch Dateien und Verzeichnisse, die von den genmounteten Filesystemen verdeckt werden, oder es gibt im root-Verzeichnis versteckte Dateien oder Verzeichnisse, die daher auch nicht von "du -sh *" oder "ls -ghS" angezeigt werden.

Übrigens, die 640mb von /proc können auch noch abgezogen werden. /proc ist auch ein Mountpoint und da es sich hier um ein virtuelles Filesystem handelt, benötigt /proc auch keinerlei Festplatten-Speicherplatz.

Gruß
gms

[cotwild]

vielen dank erstmals für eure schreibkraft!

leider habe ich momentan noch keinen physischen zugriff auf das system gehabt, um lokal / mit fsck zu checken.

doch mir ist nun noch etwas aufgefallen. ich habe zu testzwecken etwas platz auf /home freigeschaufelt und beobachtet, wie sich der platz verhält, während ich diverse dienste benütze..

auf meinem server läuft kplaylist (http://www.kplaylist.net), eine musikdb, die online (mit login, zu privaten zwecken) zugänglich ist. ich bei diesem projekt auch mitentwickelt und unter anderem das ganze mit lame kombiniert, um bei schwächeren internetleitungen auch flüssig musik hören zu können. wenn ich nun diese funktion benutze, wird mein vorhandener platz auf / immer kleiner. kann es sein, dass lame den stream irgendwie noch auf der platte niederlegt? (nicht nur temporär?)

wie kann ich alle files auf / sichtbar machen? wie verstecke resp. zeige ich versteckte dateien an?

danke für eure hilfe..
dave

[KBDCALLS]

Ich tippe mal darauf das /tmp läuft über.Lege das mal auf eine andere Partiton. Sollte man sowieso machen. Auch /var . Falls es mal dazu kommt das etwas unvorhergesehens passiert , wird das ganze Sytem nicht lahmgelegt. Alle Dateien werden mit ls -a angezeigt.