System gibt gelöschte Dateien nicht frei

Also hier mal eine harte Nuß !?

ich habe auf meinem Linuxrechner ein paar Berechnungen durchgeführt. Die Maschine schreibt anscheinend laufend Nachrichten auf /var/log/messages und auf /var/log/messages wenn floatingpointoperationen durchgeführt werden. Die beiden Files sind jeweils 11 Gigabyte groß, so dass meine / partion voll war. Ich habe also die beiden Files gelöscht: rm .... Das hat aber nicht geholfen. Die beiden Dateien sind zwar weg aber die Partion / ist immernoch zu 100 % voll. Nach weiterem surfen bin ich dann auf den syslog gestoßen, der halt neu gestartet werden muß, damit die Dateien wirklich freigegeben werden können.
Das Starten des syslog hat leider auch nichts gebracht. es wurden zwei neue Dateien erzeugt /var/log/mess.. und warn. Beide sind jetzt recht klein. ABER die / Partition ist immernoch zu 100 % voll. Als nächstes habe ich dann das System bebootet. ABER auch das hat nichts gebracht. Dann habe ich mit find.... mir alle Dateien rausschreiben lassen, die vielleicht großer sind, habe aber keine gefunden.
Irgendwie gibt der Rechner den Plattenplatz nicht frei. df -hk zeigt immer 100 % auf der Platte an und ich kann auch nichts auf der / speichern ohne Fehlermeldung
Zum System: suse 9.x enterprise, ist so ein 2 cpu System, die Platte hatte vor der Berechnungsaktion nur 12% Auslastung

Solange die Datei noch von irgend einem Programm im Zugriff ist wird
der Platz nicht freigegeben.

Damit kannst du sehen wer die Datei noch im Zugriff hat.
lsof | grep <filename>

Bei log-Dateien ist das meistens der logger.
=> logrotate ist ein Hilfsprogramm um so etwas zu lösen.
=> Manchmal verträgt das benutzende Programm ein "kill -SIGHUP <pid>"

Ansonsten ist die Datei nach einem Neustart weg. (viel ältere) logger sind manchmal hartnäckig..

Haveaniceday

Erstmal Danke für die Antwort...aber

es gibt ja jetzt zwei neue Dateien /var/log/messages und warn (die kleinen) und die alten (grossen) halt nicht mehr.
also zeigt mir der Befehl doch nur an, dass auf die neuen Dateien zugegriffen wird.

dann habe ich nur eine möglichkeit, wenn neben dem syslog noch ein anderes programm zugreifen sollte....

das mit dem neustart habe ich ja schon mehrfach versucht, aber das hat nicht geholfen.


alles sehr sonderbar

Dann zeigt noch etwas anderes auf die Dateien.
Gib mal ein: ( als root )

Damit findest du alle Dateien > 500 MB.
Schau mal nach ob die Dateien noch woanders liegen. ( von einem hardlink )


Wenn eine Datei gelöscht ist, kein Hardlink mehr auf sie zeigt und die
Zugriffe durch reboot beendet werden sind sie weg !
Die Anzahl der Links auf eine Datei siehst du mit ls -l, es ist die erste Zahl in der Zeile.

Mit den gelöschten Dateien sieht das so aus:

haveaniceday

Hi,

Das werde ich ausprobieren...

der Find-befehl sieht etwas anders aus als der, den ich benutzt habe.

das system hat 4 platten mit jeweils 146 GB
die erste platte hat 25 als root
dann noch 80 Gb Daten
eine partition als root2 mit 25 GB (die ist aber frei)
und dann noch solche efi-verzeichnisse???

ich werde die tips am dienstag austesten

was mich wundert ist, dass diese dateien überhaupt in der größe auftauchen, nur weil der rechner rechnet. derrechner wurde vor 6 wochen in betrieb genommen und lief so lala. und dann die erste großere rechnung und peng...

vielleicht noch eine info

der rechner hat 2 cpu's, jeweils auf einem blade. es gibt 2 ip adressen, über die ich auf den rechner zugriff habe (keine graka installiert) . über einen sog. l2-controller kann ich auf das system zugreifen ohne das der hauptrechner überhaupt an ist. (wenn der strom da ist, ist auch l2 aktiv) kann es sein, das dieser l2 controller auch diese dateien zugreift und damit die files loggt?

gruesse und danke für die hilfe... ich werde berichten wie die sache ausgeht...

linixda schrieb:

Die beiden Files sind jeweils 11 Gigabyte groß, so dass meine / partion voll war.

Zum Vergrößern anklicken....

Wie schon erwähnt: logrotate wäre ein Mittel um so etwas in Zukunft zu vermeiden.

logrotate...jajajaja

das stimmt. aber wenn sowas von der lieferfirma nicht richtig eingestellt wird, dann gibt es probleme. (für ein beispiel für die conf datei waere ich dankbar!) der rest ist wahrscheinlich auch noch nicht richtig konfiguriert z.b. samba etc aber das ist ein anderes thema

wir haben natuerlich einen servicevertrag.....0180...da gibt es dann ein callcenter in indien oder england und die dummen sprüche ...ganz schlimm

das mit dem compi ist eigentlich nicht mein thema, aber ich muss die sims auf dem system machen und wenn der rechner nicht funzt hab ich pause....

Das -xdev bei dem find / sucht nur auf der Partition /

Wenn du /var/ auf einer anderen Partition kannst du find /var ...... nehmen.

Mit den nicht gelöschten Dateien ist so eine Sache. Kann ganz schön verwirrend
sein wenn der Platz nicht wieder kommt.

logrotate -> dazu schau dir mal die Manpage an und in deinem Fall wahrscheinlich
/etc/logrotate.conf und /etc/logrotate.d/syslog

Aber bei solche großen Logdateien warn und messages, da sollte man mal durchaus einen Blick da rein werfen, manchmal bringen irgendwelche Hardwareproblemchen solche Mammutdateien zustande, manchmal hat man auch der /etc/syslog.conf ein bisschen viel konfiguriert, und manchmal hat man bei irgend einem Programm einen Tracelevel eingeschaltet .

Je nach Verwendungstype eines Servers und dessen Aufgaben und Auslastung ist es durchaus gebräuchlich /var auf eine eigenen Partition zu legen, damit das Rootfilesystem bei sochen Problemen nicht volläuft und damit der Rechner komplett blockiert.

robi

linixda schrieb:

das stimmt. aber wenn sowas von der lieferfirma nicht richtig eingestellt wird, dann gibt es probleme.

Zum Vergrößern anklicken....

Wenn die Lieferfirma logrotate (oder eine Alternative Lösung) nicht installiert/konfiguriert und darauf nicht hinweist dann liefern sie ein fehlerhaftes Produkt aus. In Deutschland gilt Produkthaftung, ist bei Lieferung etwas derart fehlerhaft konfiguriert wird dann gibts Nachlass (außer natürlich in den AGBs oder Vertag steht was gegenteiliges).

Jedem Idioten sollte klar sein das Logs Platz benötigen!

linixda schrieb:

wir haben natuerlich einen servicevertrag.....0180...da gibt es dann ein callcenter in indien oder england und die dummen sprüche ...ganz schlimm

Zum Vergrößern anklicken....

Ja, das tolle Thema "Outsourcing". Wenn die Manager, die sowas beschließen mit denselben Konditionen leben müssten wäre es kein Thema.

Hallo , ich hab jetzt mal die tipps befolgt

1. die Befehle lsof |grep warn bzw messages zeigen
bei warn an, dass der syslogd drauf zugreift

und bei messages: gibt es gar kein programm, das zugreift ???
der findet da nur .../samba/messages.tdb und /var/log/localmessages und darauf greift der syslogd zu

2. Der befehl:
find / -xdev -size +500M -exec ls -l {} \; 2>/dev/null

zeigt gar nichts an. ist da die syntax richtig wg. >/dev/null und dem 500M ????
also ich wuerde die umleitung weglassen und die zahl (500M) ausschreiben....

dann zeigt mir der befehl nur ein file /proc/kcore an mit 770GByte... soviel platte habe selbst ich nicht. dieses File ist aber wohl nur virtuell

3.
ls -l messages zeigt ein programm an 1 als erste zahl an
ebenso ls -l warn


nun gut... bis jetzt funzt es noch nicht....

linixda schrieb:

3.
ls -l messages zeigt ein programm an 1 als erste zahl an
ebenso ls -l warn

Zum Vergrößern anklicken....

die 1 da ist kein Programm oder Prozess, sondern die Anzahl von Namen die diese Datei hat. gib mal bitte die Ausgabe von

ls -l warn* messages* damit wir überhaupt mal sehen wie groß deine Dateien sind, und ob und wie logrotate dort arbeitet.

robi

hallo,

also die dateien sind momentan nicht sehr groß:

131072 für messages und
65536 für warn.

die beiden dateien sind ja neu. aber die alten (11 GByte) dateien werden nicht freigegeben, so dass ich immer auf der / partition 100% habe.

linixda schrieb:

die beiden dateien sind ja neu. aber die alten (11 GByte) dateien werden nicht freigegeben, so dass ich immer auf der / partition 100% habe.

Zum Vergrößern anklicken....

desshalb solltest du ja auch einen * dahinter machen, damit man mal sehen kann ob sie eventuell umbenannt sind, somit bleibt uns hier nur Rätselraten:
kann sein, dass dein Filesystem voll ist, das er dadurch nicht in die messages reinschreiben kann aber genau damit einen weiteren Fehlereintrag produziert, also ein Kurzschluss im Logging, dazu müßtest du mal in die Dateien reinschauen, was da gelogt wird.

kann sein, dass die Datei umbenannt wurde und zB ein Komprimierungsprogramm darauf zugreift aber nicht weiterarbeiten kann weil das Filesystem voll ist. Dazu könntest du mal ein ls -l * aufrufen

Kann sein, das die Datei zwar schon vom logrotate-Prozessen gelöscht wurde, aber noch ein Prozess darauf zugreift, zB gzip oder so was.
Das könntest du eventuell mit lsof -a +L1 / herausfinden.

Ansonsten könnte helfen, wenn du dich mal mit du -sk * durch dein Rootfilesystem hangelst, um zu sehen in welchem Verzeichniss übermäßig viel Plattenplatz verbraucht wird.

robi

Hi robi,

das mit dem * führt zu keinen weiteren (anderen) ergebnissen

ls -l * zeigt keine größeren dateien an. auffällig sind die Dateien
mit y2log, y2log-1 bis -5

der Befehl losf -a +L1 / zeigt
zwei zeilen (processe mit der gleichen PID) an
hwscand ... /var/run/hwscand.pid (deleted)

und du -sk * zeigt alle verzeichnisse an.
124044 var
2014352 usr
189004 lib

der größte ist

759038676 proc aber das sollte kein problem sein


trotzdem vielen dank

Hi

also hier die "Lösung" des Problems. Der Form halber...

Es handelt sich wohl definitiv um einen Bug im Betriebssystem des Rechners. Wenn die Files /var/log/messages und warn gelöscht werden dann hält der Prozess syslog die Files noch auf der Platte fest. D.H. keine Freigabe der Dateien. Es werden aber neue Dateien produziert.

Also in Zukunft:

/etc/rc.d/syslog stop
rm /var/log/messages
rm /var/log/warn
/etc/rc.d/syslog start

Wie bin ich nun wieder an den Platten-Speicher gekommen?

Vorgehen: von cd booten und ein fs_repair machen.

Ein weiteres Probelm war, daß das Telnet-Programm auf meinem windows-client den telnet nicht richtig emuliert. Bei dem Programm Putty bin ich mir nicht sicher, ob es funtioniert hätte.
Also habe ich das Booten von einem anderen Linux Rechner aus durchgeführt (über xterm), den fs_repair auf der /dev/... gemacht (vorher platte einmal mounten und unmounten , ganz wichtig !!!) und anschließend wieder die Maschine gestartet. Jetzt funktioniert das wieder.


Gruesse und danke für die Diskussion zum Thema