Debian - Serverfestplatte wird "ohne Grund" immer mehr voll

Mach mal "ls -la", damit auch die versteckten Dateien auftauchen...

Aber das ist sehr merkwürdig...
 
Eventuell auch eher ein "ls -lah", damit die Größenangaben lesbarer sind.
 
Code:
root@intranet:/# ls -lah
total 116K
drwxr-xr-x  24 root root    4.0K 2014-07-01 11:52 .
drwxr-xr-x  24 root root    4.0K 2014-07-01 11:52 ..
drwxr-xr-x   2 root root    4.0K 2012-11-10 12:50 bin
drwxr-xr-x   3 root root    4.0K 2012-11-10 12:01 boot
lrwxrwxrwx   1 root root      11 2012-11-10 11:22 cdrom -> media/cdrom
drwxr-xr-x  15 root root    2.9K 2014-07-25 06:25 dev
drwxr-xr-x   3 root root    4.0K 2014-04-01 12:55 emul
drwxr-xr-x 102 root root    4.0K 2014-07-25 14:05 etc
drwxr-xr-x   4 root root    4.0K 2012-11-10 12:50 home
lrwxrwxrwx   1 root root      34 2012-11-10 11:24 initrd.img -> boot/initrd.img-2.6.32-trunk-amd64
drwxr-xr-x  11 root root     12K 2012-11-11 01:31 lib
lrwxrwxrwx   1 root root       4 2012-11-10 11:23 lib64 -> /lib
drwx------   2 root root     16K 2012-11-10 11:22 lost+found
drwxr-xr-x   4 root root    4.0K 2012-11-10 11:22 media
drwxr-xr-x  14 root root    4.0K 2014-07-23 12:02 mnt
drwxrwxr-x   3 root msadmin 4.0K 2014-03-11 16:26 msbackup
drwxr-xr-x   3 root root    4.0K 2014-05-12 13:07 msbackup2
drwxr-xr-x   5 root root    4.0K 2013-10-08 14:28 opt
dr-xr-xr-x 229 root root       0 2014-07-22 16:59 proc
drwxr-xr-x  11 root root    4.0K 2014-07-25 14:37 root
drwxr-xr-x   2 root root    4.0K 2013-10-30 14:13 sbin
drwxr-xr-x   2 root root    4.0K 2008-09-16 09:22 selinux
drwxr-xr-x   2 root root    4.0K 2012-11-10 11:23 srv
drwxr-xr-x  13 root root       0 2014-07-22 16:59 sys
drwxrwxrwt   5 root root    4.0K 2014-07-25 14:59 tmp
drwxr-xr-x  11 root root    4.0K 2012-11-10 12:49 usr
drwxr-xr-x  16 root root    4.0K 2014-07-01 11:52 var
lrwxrwxrwx   1 root root      31 2012-11-10 11:24 vmlinuz -> boot/vmlinuz-2.6.32-trunk-amd64
-rw-r--r--   1 root root    9.7K 2014-07-01 11:54 webmin-setup.out
root@intranet:/#
 
Immer noch nichts auffälliges zu erkennen. Aufschlussreich wäre auch mal, wenn du nicht immer nur eine einzelne Ausgabe der Befehle postest, sondern einmal jeweils direkt nach nem Reboot die Infos von "ls -alh /" und "du -sh" bzw. "ncdu" ausgeben lässt und dann nochmal zu einem Zeitpunkt, wo merklich mehr Plattenplatz verbraucht wird.

Dann würde man in der Gegenüberstellung möglicherweise auch erkennen, wo die magische Datenvermehrung stattfindet.
 
Dreamer90 schrieb:
# du -sh ...
0 /cdrom
584K /dev
80K /emul
15M /etc
4.7G /home

Nur son Hinweis: Man würde weniger Hirn und Augen verbiegen müssen, wenn man mit "du -ms ..." die Größe der Verzeichnisse ermitteln würde. Dann würden alle Größen einheitlich in Megabyte angezeigt statt in jeder Zeile eine andere Maßeinheit. Die Option -h von du steht zwar für "human readable", meint aber entweder Marsmenschen oder bezieht sich nur auf einzelne Zahlen.
 
Zuletzt bearbeitet:
und so sieht es heute aus... reboot kann ich leider erst morgen machen, wenn ich in der nähe vom server bin (zur sicherheit).
Ein zweiter Server hat jetzt genau das selbe Problem... der Zweite steht in einem RZ und hat eine XEN VM installiert, wobei nur der Physikalische Host vollläuft...... echt ärgerlich, denn mit du -sh / -sm df -h kann ich auch auf dem nicht das problem lokalisieren.

Code:
du -sh /* --exclude msbackup --exclude msbackup2 --exclude mnt
4.8M    /bin
20M     /boot
0       /cdrom
584K    /dev
80K     /emul
15M     /etc
4.7G    /home
0       /initrd.img
106M    /lib
0       /lib64
16K     /lost+found
12K     /media
99M     /opt
du: cannot access `/proc/19117/task/19117/fd/4': No such file or directory
du: cannot access `/proc/19117/task/19117/fdinfo/4': No such file or directory
du: cannot access `/proc/19117/fd/4': No such file or directory
du: cannot access `/proc/19117/fdinfo/4': No such file or directory
0       /proc
120M    /root
4.2M    /sbin
4.0K    /selinux
4.0K    /srv
0       /sys
16K     /tmp
1.2G    /usr
2.9G    /var
0       /vmlinuz
12K     /webmin-setup.out
root@intranet:/# df -m
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/sda1               225381    100534    113399  47% /
 
Zuletzt bearbeitet:
Wie schon gesagt, wichtig wäre auch mal die Ausgaben der Befehle direkt nach dem reboot und dann vielleicht stündlich, wenn das ausreicht, um schon Veränderungen zu erkennen.
Immer einzelne Auszüge, dann noch von verschiedenen Servern, ist nutzlos...

Nächste Fragen / Ideen:
-welche Dienste / Anwendungen laufen auf den Servern ?
-lassen sich hier vielleicht Parallelen ziehen ?

Hast du mal versucht, bis auf ssh alle Dienste zu stoppen ?
Dann lässt du es eine Stunde so laufen und überprüfst, ob weniger Platz verfügbar ist.
Wenn nicht, einen Dienst dazu, nach ner Stunde wieder das selbe...

So kann man evtl. den Übeltäter eingrenzen.

EDIT:
und noch ne Idee:

Anscheinend gibt es eine Diskrepanz zwischen df und du, wenn Dateien als "gelöscht" markiert sind, ein Prozess aber noch auf sie zugreift und folglich nicht gelöscht werden können. So werden nur die Verweise auf die Datei im Dateisystem gelöscht, jedoch (noch) nicht der Speicherplatz freigegeben.

Bitte mal
Code:
lsof +L1
und
Code:
lsof | grep deleted
posten.

Der erste Befehl such nach offenen Dateien, die weniger als einmal verlinkt werden.
Der zweite Befehl such nach offenen Dateien, die im Dateisystem schon als gelöscht markiert sind, aber noch offen sind.
 
Zuletzt bearbeitet: (Ergänzungen)
zwiebelchen schrieb:
Wie schon gesagt, wichtig wäre auch mal die Ausgaben der Befehle direkt nach dem reboot und dann vielleicht stündlich, wenn das ausreicht, um schon Veränderungen zu erkennen.
Immer einzelne Auszüge, dann noch von verschiedenen Servern, ist nutzlos...

Nächste Fragen / Ideen:
-welche Dienste / Anwendungen laufen auf den Servern ?
-lassen sich hier vielleicht Parallelen ziehen ?

Hast du mal versucht, bis auf ssh alle Dienste zu stoppen ?
Dann lässt du es eine Stunde so laufen und überprüfst, ob weniger Platz verfügbar ist.
Wenn nicht, einen Dienst dazu, nach ner Stunde wieder das selbe...

So kann man evtl. den Übeltäter eingrenzen.

Diese Auszüge sind alle von dem selben Server der im Intranet steht.

Leider kann ich nicht alle Dienste stoppen und nein ich weiß auch gar nich welche alle darauf laufen, weil ich der nachfolger Sysadmin bin.
Lediglich Webmin habe ich dauz installiert, aber das Problem war schon lange davor.

Auf dem Intranet Server laufen viele Testseiten für Kunden, also nein ich kann nicht alle Dienste bis auf SSH Stoppen.

Meine Idee wäre ein Tool zu installieren, mit dem man Schreibaktivitäten von Prozessen aufzeichnen kann, gibt es so eines?
 
root@privatehost32:/var# lsof +L1
root@privatehost32:/var# lsof | grep deleted
root@privatehost32:/var#

keine Ausgabe

EDIT: Sorry oben war der falsche Server :D

Code:
root@intranet:~# lsof +L1
COMMAND  PID  USER   FD   TYPE DEVICE        SIZE NLINK     NODE NAME
mysqld  2333 mysql    3w   REG    8,1 96700644550     0  5690362 /var/log/mysql/mysql.log.1 (deleted)
mysqld  2333 mysql    5u   REG    9,0           0     0 38684455 /mnt/intranet/var/www/ispcp/gui/phptmp/ibrW8qox (deleted)
mysqld  2333 mysql    6u   REG    9,0         108     0 38684457 /mnt/intranet/var/www/ispcp/gui/phptmp/ibk7EyRH (deleted)
mysqld  2333 mysql    7u   REG    9,0           0     0 38684458 /mnt/intranet/var/www/ispcp/gui/phptmp/ibEPAGkS (deleted)
mysqld  2333 mysql    8u   REG    9,0           0     0 38684459 /mnt/intranet/var/www/ispcp/gui/phptmp/ibRSyIU2 (deleted)
mysqld  2333 mysql   12u   REG    9,0           0     0 38684460 /mnt/intranet/var/www/ispcp/gui/phptmp/ibjxeKXl (deleted)
smbd    2790  root    2w   REG    8,1      163425     0  5728985 /var/log/samba/log.smbd.1 (deleted)
smbd    2790  root    6w   REG    8,1      163425     0  5728985 /var/log/samba/log.smbd.1 (deleted)

anscheinend wurde das Problem jetzt endlich gefunden, wie verhindere ich jetzt das es nochmal passiert?

EDIT:
falls jemand das selbe Problem hat und eventuell viele "gelöschte" Files hat, welche Speicherplatz verbrauchen, folgendes Skript funktioniert gut:

Code:
lsof | grep "(deleted)$" | sed -re 's/^\S+\s+(\S+)\s+\S+\s+([0-9]+).*/\1\/fd\/\2/' | while read file; do bash -c ": > /proc/$file"; done

EDIT2: Leider ändert sich die Filegröße wieder schön langsam... Verstehe nicht warum er in ein altes Log schreibt?


Das beste ist das normale mysql.log ist leer...

Code:
-rw-r-----  1 mysql adm          0 2014-07-27 06:25 mysql.log
drwxr-s---  2 mysql adm       4096 2014-07-27 06:25 .
drwxr-xr-x 21 root  root      4096 2014-07-27 12:00 ..
root@intranet:~# lsof | grep deleted
mysqld     2333       mysql    3w      REG                8,1  186958450    5690362 /var/log/mysql/mysql.log.1 (deleted)

Code:
my.conf

log             = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log_slow_queries       = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                        = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
 
Zuletzt bearbeitet:
EDIT:
falls jemand das selbe Problem hat und eventuell viele "gelöschte" Files hat, welche Speicherplatz verbrauchen, folgendes Skript funktioniert gut:
Hier von halte ich nicht viel, da ja noch ein offenere FileDescriptor besteht und man sich so evtl. Probleme einhandeln kann. Zumal ist das nur eine Bekämpfung der Symptome, nicht der Ursache.

Hast du mal (wahrscheinlich am besten nach einem mysql restart, wenn sie noch nicht zum Löschen markiert sind) in die Logs reingeschaut ?

Hast du für MySQL eine Logrotate-Config ?

Vielleicht hilft das:
http://www.question-defense.com/2009/12/20/configure-logrotate-to-rotate-and-flush-mysql-logs-without-a-password

Sry, MySQL benutze ich nicht und kenne mich da auch wenig aus.
 
Zuletzt bearbeitet:
zwiebelchen schrieb:
Hier von halte ich nicht viel, da ja noch ein offenere FileDescriptor besteht und man sich so evtl. Probleme einhandeln kann. Zumal ist das nur eine Bekämpfung der Symptome, nicht der Ursache.

Hast du für MySQL eine Logrotate-Config ?

Vielleicht hilft das:
http://www.question-defense.com/2009/12/20/configure-logrotate-to-rotate-and-flush-mysql-logs-without-a-password

Sry, MySQL benutze ich nicht und kenne mich da auch wenig aus.

Ja da hast du natürlich recht.
Habe mysql gekilled (da ein restart nicht funktionierte und der FileDescriptor wurde schön entfernt), dass system an sich scheint mir etwas suspekt, nichts desto trotz arbeite ich auf diesem zumindes mit "never touch a running system".
Solange es nicht wieder volläuft werde ich hier nichts ändern. Log Rotate ist aktiviert, jeden tag wird ein neues File generiert. Keine Ahnung warum in das gelöschte File geschrieben wurde.
 
Zuletzt bearbeitet: (Übrigens Herzlichen Dank für Eure hilfe!)
Zurück
Oben