Beiträge von althoffc

Hallo,

ich habe die Ursache des unerwarteten Platzbedarfes (du) gefunden.
Die gelöschte Datei (35 GB) ist noch als offene Datei vorhanden.

lsof liefert (mehrfach) die zuvor gelöschte Datei.

:~ # lsof | grep catalina.out
java      10991   tomcat    1w      REG               8,17 36631190568     673288 /home1/apache-tomcat-6.0.37/logs/catalina.out (deleted)
java      10991   tomcat    2w      REG               8,17 36631190568     673288 /home1/apache-tomcat-6.0.37/logs/catalina.out (deleted)
java      16431   tomcat    1w      REG               8,17 36631190568     673288 /home1/apache-tomcat-6.0.37/logs/catalina.out (deleted)
java      16431   tomcat    2w      REG               8,17 36631190568     673288 /home1/apache-tomcat-6.0.37/logs/catalina.out (deleted)
java      18187   tomcat    1w      REG               8,17    22280330     129782 /home1/apache-tomcat-6.0.37/logs/catalina.out
java      18187   tomcat    2w      REG               8,17    22280330     129782 /home1/apache-tomcat-6.0.37/logs/catalina.out
java      21681   tomcat    1w      REG               8,17 36631190568     673288 /home1/apache-tomcat-6.0.37/logs/catalina.out (deleted)
java      21681   tomcat    2w      REG               8,17 36631190568     673288 /home1/apache-tomcat-6.0.37/logs/catalina.out (deleted)

Wie kann ich diese (gelöschte) Datei schließen/löschen, um den Speicherplatz wieder freizugeben?

Gruß
Carsten

Hallo,
habe folgendes Problem:
eine sehr große Protokolldatei (35 GB) wurde manuell mit rm in einem Unterverzeichnis von /home1 gelöscht.
Ich erhalte jedoch unterschiedliche Angaben zum Platzbedarf von df -h und du -h --max-depth=1.

Mit du -h --max-depth=1 im Verzeichnis /home1 erhalte ich folgende Angaben:

4.2G    ./dir1
    22M     ./dir2
    801K    ./dir3
    1.4G    ./dir4
    143M    ./dir5
    0       ./dir6
    6.1M    ./dir7         
    16M     ./dir8
    118M    ./dir9
    6.6G    ./dir10        
    47G     ./dir11     
    222K    ./dir12    
    60G     .

Die Angaben zum Platzbedarf sind nach dem Löschen der Protokolldatei (35 GB) im Unterverzeichnis dir1 korrekt.

Zuvor wurde für ./dir1 ein Platzbedarf von ca. 39 GB angegeben. In Summe belegt /home1 gemäss du ca. 60 GB.

df -h liefert dagegen Folgendes:

Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda2             7.3G  6.7G  654M  92% /
    udev                  3.9G   92K  3.9G   1% /dev
    /dev/sdb1             120G   93G   28G  78% /home1

Der Platzbedarf für /home1 (sdb1, reiserfs) wird zu 93 GB ermittelt. Hier hätte ich nach dem Löschen aber eher 93 GB - 35 GB = 58 GB erwartet.

/etc/fstab beinhaltet Folgendes:

/dev/sda2            /                    reiserfs   acl,user_xattr        1 1
    /dev/sda1            swap                 swap       defaults              0 0
    proc                 /proc                proc       defaults              0 0
    sysfs                /sys                 sysfs      noauto                0 0
    debugfs              /sys/kernel/debug    debugfs    noauto                0 0
    devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
    /dev/fd0             /media/floppy        auto       noauto,user,sync      0 0
    /dev/sdb1            /home1               reiserfs   acl,user_xattr        1 2

Systeminformationen:

# cat /etc/issue
    Welcome to SUSE Linux Enterprise Server 10 SP4  (x86_64) - Kernel \r (\l).
    :/etc # uname -a
    Linux kgt-linux1 2.6.16.60-0.85.1-smp #1 SMP Thu Mar 17 11:45:06 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Gibt es eine "Papierkorb"-Funktion, so dass ich den Papierkorb erst leeren muss, damit der Platz der gelöschten Datei tatsächlich freigegeben wird?
Wie kann ich dann einen solchen "Papierkorb" (in einer Shell) leeren?

Gibt es evtl. andere Ursachen für die unterschiedlichen Angaben von df und du ?

Gruß
Carsten

Hallo zusammen,

habe den Fehler gefunden:

Das Verzeichnis /terra wurde für den Mount eines externen Laufwerks (anderer Rechner) verwendet.
In dieses Verzeichnis werden täglich Sicherungen (also auf das Laufwerk eines anderen Rechners) geschrieben.

Durch einen vorherigen Missglückten Rechnerstart (terra) konnte das Verzeichnis terra nicht gemountet werden. Dadurch liefen mehrere Sicherungen in das Verzeichnis /terra auf dem lokalen Rechner und belegen unerwartet/ungeplant Speicherplatz auf der lokalen Platte.

Nachdem der Rechner terra vor einigen Tagen neu gestartet wurde und dessen Laufwerk wieder korrekt gemountet werden kann, waren die lokalen Dateien im Verzeichnis /terra für du nicht mehr sichtbar.

Nun habe ich auf dem lokalen Rechner alle mounts aufgehoben und in dem Verzeichnis /terra die Sicherungsdateien vorgefunden, die genau die vermissten 17 GB Speicherplatz beanspruchen.

Problem somit gelöst bzw. Erklärung für den Speicherbedarf gefunden.

Gruß
althoffc

Hallo,

die Anzahl der inodes kann es auch nicht sein. df -i liefert ausreichend freie inodes für die Partition sda2:

>df -i
Dateisystem                     	Inodes IBenutzt  	IFrei IUse% Eingehängt auf
/dev/sda2                      	1995280   416457	1578823   21% /
udev                                 	0    	0      	0 	- /dev
tmpfs                           	111221    	1 	111220	1% /dev/shm
/dev/sdb1                      	2097152	12596	2084556	1% /data1
/dev/sdc2                      	2003120   	12	2003108	1% /platte3
terra2.ifax.de:/mnt/array1/k300 1332353328  2085757 1330267571	1% /terr

Der Rechner wurde im Juli eingerichtet, läuft seitdem aber nicht ununterbrochen. In den letzten Tagen wurde der Rechner aufgrund dieser Problematik mehrmals neu gebootet. Hängende Prozesse können deshalb wohl ausgeschlossen werden.
lsof | grep delete liefert keine Treffer.:

>lsof | grep deleted
>lsof | grep 'deleted'
>

Wenn in Summe 17 GB von 31 GB auf der Partition für administrativen Overhead des Dateisystems benötigt würde, wäre das doch ziemlich traurig, oder?

Es bleibt also die Frage: Wodurch gehen 17 GB Speicherplatz (mehr als 50 % der Partition mit 31 GB Kapazität) verloren, wenn dies nicht an Dateien ausgemacht werden kann?

gruß
althoffc

So,

hier das Ergebnis von du als root ausgeführt.
Leider ergibt sich kein entscheidender Unterschied. Im Vergleich zu df ist auch mit diesen du-Ausgaben eine Differenz des belegten Speicherplatzes von ca. 17 GB zu erkennen. (Dateisystem ist ext3).

Was könnte sonst noch Ursache für diesen Unterschied sein? Problem ist eben auch, dass gemäß df-Ausgabe 95% der Platte belegt sind und nicht viel "Luft" zum Arbeiten bleibt. (Es waren zuvor 100% Belegung erreicht, so dass ich erst einige Dateien löschen musste, um überhaupt wieder Dateien speichern zu können.)

Gruß
althoffc

# du -hd1 --exclude=terra --exclude=platte3 --exclude=data1
4,0K	./terra_qm
4,0K	./media
1,1G	./usr5
6,9M	./tmp
96M 	./etc
0   	./sys
58M 	./boot
88K 	./srv
du: Zugriff auf »./proc/28277/task/28277/fd/4« nicht möglich: Datei od
du: Zugriff auf »./proc/28277/task/28277/fdinfo/4« nicht möglich: Date
du: Zugriff auf »./proc/28277/fd/4« nicht möglich: Datei oder Verzeich
du: Zugriff auf »./proc/28277/fdinfo/4« nicht möglich: Datei oder Verz
0   	./proc
1,6G	./usr2
16K 	./lost+found
896M	./opt
19M 	./lib64
44M 	./root
14M 	./sbin
262M	./lib
4,0K	./mnt
39M 	./home
4,0G	./usr
108K	./dev
du: Zugriff auf »./var/lib/ntp/proc/28277/task/28277/fd/4« nicht mögli
du: Zugriff auf »./var/lib/ntp/proc/28277/task/28277/fdinfo/4« nicht m
du: Zugriff auf »./var/lib/ntp/proc/28277/fd/4« nicht möglich: Datei o
du: Zugriff auf »./var/lib/ntp/proc/28277/fdinfo/4« nicht möglich: Dat
1,6G	./var
4,0K	./selinux
9,2M	./bin
9,6G	.

Hallo,

ich werde den Tipp verfolgen, du als root auszuführen und schauen, welcher belegter Speicherplatz dann ermittelt wird.

Anmerkung:
Ich finde den Ton, den die Antwortgeber untereinander anschlagen, schon etwas ... befremdlich. Als neues Mitglied hier im Forum finde ich einen solchen Umgangston nicht gerade einladend und motivierend.

Gruß
althoffc

Hallo,
ich hoffe hier die passende Rubrik im Forum gefunden zu haben:
Die Tools df und du liefern sehr unterschiedliche Angaben zum Speicherplatzbedarf für die root-Partition sda2.
df gibt 27 GB als verwendeten Speicherplatz an (von 31 GB auf der Partition sda2).
du hingegen gibt nur 9,4 GB an Speicherbelegung an.

>df -h
Dateisystem                     Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2                         31G     27G  1,7G   95% /
udev                             435M    108K  435M    1% /dev
tmpfs                            435M       0  435M    0% /dev/shm
/dev/sdb1                         32G     12G   19G   40% /data1
/dev/sdc2                         31G     11G   19G   35% /platte3
terra2.ifax.de:/mnt/array1/k300  1,4T    1,1T  318G   77% /terra

>du -hd1 --exclude=terra --exclude=data1 --exclude=platte3 2>/dev/null
4,0K    ./terra_qm
4,0K    ./media
1,1G    ./usr5
6,8M    ./tmp
96M     ./etc
0       ./sys
58M     ./boot
88K     ./srv
0       ./proc
1,6G    ./usr2
16K     ./lost+found
896M    ./opt
19M     ./lib64
4,0K    ./root
14M     ./sbin
262M    ./lib
4,0K    ./mnt
4,9M    ./home
4,0G    ./usr
108K    ./dev
1,5G    ./var
4,0K    ./selinux
9,2M    ./bin
9,4G    .

Es ergibt sich ein Unterschied der angegebenen Speicherplatzbelegung von ca. 27 GB - 9,4 GB ~ 17 GB.
Woher kann ein solcher Unterschied bei der Speicherplatzbelegung herkommen?
Gibt es Tools, mit denen man der Ursache auf die Spur kommen und ggf. beheben kann?
Verwendetes Dateisystem ist ext3.
Gruß
althoffc

Hallo,

ich hoffe mir kann jemand helfen.
Für das Debuggen von Cobol-Programmen soll ein Process-Trace (ptrace) ermöglicht werden. Nun habe ich gelesen, dass seit einigen SuSE-Distributionen PTRACE_SCOPE per Default auf 0 gesetzt wird, so dass nur Kind-Prozesse verfolgt werden können.
Zum Debuggen muss aber ein "Vater"-Prozess verfolgt werden.

Es wird ein Telnet-Terminal (Windows) gestartet, welches den nachfolgend gestarteten Debug-Prozess (SLES11) tracen soll.
Es erfolgt dann aber eine Meldung Unable to attach to active debuggee process.

1. Wie kann ich feststellen welcher Wert aktuelle für PTRACE_SCOPE gesetzt ist?
2. Wie kann ich für einen einzelnen Debug-Prozess (nicht Systemweit) einen Prozess-Trace für einen Vater-Prozess erlauben?

Danke und Gruß
Carsten Althoff

Verwendete Umgebung:
SLES11
Linux sles113.0.76-0.11-default #1 SMP Fri Jun 14 08:21:43 UTC 2013 (ccab990) x86_64 x86_64 x86_64 GNU/Linux
VisualCobol 2.2
V2.2 revision 2 build 10/10/2 G; 27714. Run Time System KXCSU/AA0/00000V