Sie haben einige außer Kontrolle geratene Protokolle. Statt wie verrückt jeden Tag zu löschen, findet die schnell wachsende Datei oder Dateien, und Blick nach innen zu untersuchen , was dies verursachen kann. Möglicherweise dreht sich ein Programm in einer Schleife und protokolliert einen bestimmten Zustand. Deaktivieren Sie das Programm, deaktivieren Sie die Protokollierung, oder versuchen Sie, den Zustand zu beheben, über den es sich beschwert.
Wenn eine Datei vor Ihren Augen wächst und Sie keine Ahnung haben, welches Programm darauf schreibt, können Sie dies möglicherweise leicht herausfinden. Hier ist ein Beispiel. Wer hat /var/log/sysloggeöffnet? Wir benutzen den fuserBefehl:
# fuser /var/log/syslog
/var/log/syslog: 602
Es ist nur ein Prozess /var/log/syslogoffen. Es ist Prozess 602. Was ist das? Lassen Sie uns nicht mit psund befassen grep, sondern schauen Sie sich das /procDateisystem direkt an:
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
Aha, das ist es rsyslogd. Wir sind nicht überrascht , dass rsyslogdhat /var/log/syslog/geöffnet.
Diese Methode funktioniert garantiert nicht. Der Grund dafür ist, dass Programme Dateien nicht geöffnet halten müssen, um darauf schreiben zu können. Angenommen, Sie haben einen Prozess, der eine Datei öffnet, an sie anfügt und sie dann schließt. Sie werden eine etwas schwierigere Untersuchung haben. Sie könnten fuserviele Male laufen, bis Sie zufällig den Prozess "auf frischer Tat" abfangen. Dieser Prozess selbst könnte schnell ein- und ausgehen. Ein weiteres Problem besteht darin, dass die Datei bei mehreren Prozessen möglicherweise geöffnet ist, aber nur einer vergrößert sie. In diesem Fall können Sie die Systemaufrufe verfolgen.
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
Hoppla! Zwei Prozesse haben es geöffnet: 1234 und 23459. Mal sehen, was sie tun:
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
Es tut nichts, es blockiert nur einen selectAnruf. Strg + C, um den Trace zu unterbrechen:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
Überprüfen Sie den nächsten:
# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C
Hoppla, dieser schreibt ständig. Es muss der Böse sein. Wir können sogar überprüfen, ob der Dateideskriptor 5, in den der Prozess schreibt, tatsächlich die große Datei ist:
# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
Ich vermute nicht, dass Sie ein beschädigtes Dateisystem haben, aber um eine vollständige Überprüfung zu erzwingen, müssen Sie keine DVD booten.
Überprüfen Sie zunächst die maximale Anzahl der Ladevorgänge in Ihrem Dateisystem. Identifizieren Sie Ihre Partition mit dem Befehl df. Beispiel auf einem Ubuntu-System, das ich hier habe:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 18062108 5499320 11645284 33% /
udev 392152 4 392148 1% /dev
tmpfs 159768 768 159000 1% /run
none 5120 0 5120 0% /run/lock
none 399416 200 399216 1% /run/shm
/dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
Sie können sehen, dass das /Dateisystem angehängt ist /dev/sda1. So /dev/sda1ist die Speichervorrichtung der Root - Partition (und die einzigen Partition in diesem speziellen System).
Schauen wir uns einige Attribute dieses Dateisystems an. Dies ist sicher, obwohl es montiert ist. Der Befehl gibt viel aus. Hier ist ein Auszug:
$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
[ ... SNIP ... ]
Last mount time: Fri Mar 29 17:45:18 2013
Last write time: Tue Mar 5 09:08:03 2013
Mount count: 22
Maximum mount count: 22
[ ... SNIP ... ]
Hey schau, die Anzahl der Reittiere ist gleich der maximalen Anzahl der Reittiere. Beim nächsten Neustart wird das Dateisystem überprüft. Wichtig ist, dass die Anzahl der Reittiere ein positiver Wert ist. Wenn deins Null ist, ändern Sie es mit auf einen positiven Wert wie 22 tune2fs -c 22 /dev/whatever. Null bedeutet, dass niemals eine Überprüfung erzwungen wird, unabhängig davon, wie oft die Partition gemountet wurde. Selten neu gestartete Systeme sollten hier niedrige Werte haben. Ein Server, der einmal im Jahr ausfällt, könnte wahrscheinlich bei jedem Neustart ein fsck verwenden. Sie können auch datumsbasierte Prüfintervalle festlegen.
Um nun eine Überprüfung zu erzwingen, können Sie die tatsächliche Anzahl so überschreiben , dass sie größer oder gleich dem Maximum ist, und anschließend neu starten. Das ist mit der Hauptstadt gemacht C: tune2fs -C 1234 /dev/whatever. Jetzt sieht es so aus, als ob die Partition 1234-mal ohne einen Haken gemountet wurde, der größer als das ein- oder zweistellige Maximum ist.
sudo du -sh /var/* ~/.xsession-errorsplease anzuhängen ? (Diese beiden Orte würde ich wahrscheinlich in die Luft jagen, wenn es etwas Dummes gibt). Ansonsten bin ich bei Eliah - dies weist auf Festplattenprobleme hin. Nimm das ernst.