Komische Fehlermeldung wenn /dev/shm 100% Benutzt wird. SuSE11.3
Hallo Liste, sobald in /dev/shm 100% Benutzt wird bekomme ich eine Fehlermeldung in der Terminal1 (wenn ich Strg + Alt+F1) wechsle. Da steht dann: hedi-2 login: ERROR: couldn`t write to output 5 for CPU0, exiting.: Success WARNING: Number of errors: 0, skipped probes: 2201 Mein Kernel: uname -r 2.6.34.10-0.2-desktop Wenn ich danach etwas in Firefox betätige dann stürtzt mir Firefox ab. Ich kann dann Firefox erst nach einem Reboot wieder benutzen. In messages sind keine Fehlermeldungen. Das ist der Fehler in Firefox wo ich in einem anderen Threed schon mal eine neue Festplatte eingebaut habe. Hat jemand eine Idee? Viele Grüße, Heinz Dittmar -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 4. August 2011 14:27:52 schrieb Heinz Dittmar: Hallo Heinz,
sobald in /dev/shm 100% Benutzt wird bekomme ich eine Fehlermeldung in der Terminal1
Dein RAM ist voll oder defekt! Die Frage ist nun, mit was muellst Du Dir den Ram voll? Eine SWAP-Partition hast Du vermutlich auch nicht?
Wenn ich danach etwas in Firefox betätige dann stürtzt mir Firefox ab.
Ohne Speicher werden auch andere Programme ins Essen brechen!
Ich kann dann Firefox erst nach einem Reboot wieder benutzen.
Wieviel freien Speicher hast Du nach dem Reboot? df -h # schau nach tmpfs oder /dev/shm Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm
In messages sind keine Fehlermeldungen. Das ist der Fehler in Firefox wo ich in einem anderen Threed schon mal eine neue Festplatte eingebaut habe.
Es ist nicht die Platte, es ist der RAM. MfG Th. Moritz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag 04 August 2011 20:11:45 schrieb Thomas Moritz:
Am Donnerstag, 4. August 2011 14:27:52 schrieb Heinz Dittmar:
Hallo Heinz,
sobald in /dev/shm 100% Benutzt wird bekomme ich eine Fehlermeldung in der Terminal1
Dein RAM ist voll oder defekt! Die Frage ist nun, mit was muellst Du Dir den Ram voll? Eine SWAP-Partition hast Du vermutlich auch nicht? free total used free shared buffers cached Mem: 3989684 3760272 229412 0 36 1312644 -/+ buffers/cache: 2447592 1542092 Swap: 8388604 1468600 6920004
Wenn ich danach etwas in Firefox betätige dann stürtzt mir Firefox ab.
Ohne Speicher werden auch andere Programme ins Essen brechen!
Ich kann dann Firefox erst nach einem Reboot wieder benutzen.
Wieviel freien Speicher hast Du nach dem Reboot? df -h # schau nach tmpfs oder /dev/shm df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 128G 45G 84G 35% / devtmpfs 2,0G 304K 2,0G 1% /dev tmpfs 2,0G 2,0G 0 100% /dev/shm /dev/sda3 251M 68M 170M 29% /boot /dev/sda7 256G 101G 156G 40% /home /dev/sda1 40G 18G 22G 45% /windows/C /dev/sda2 20G 4,1G 16G 21% /windows/D
Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm ls -l /dev/shm insgesamt 1994840 -rw-r--r-- 1 root root 304 4. Aug 10:25 initrd_exports.sh -rw-r--r-- 1 root root 2038714368 4. Aug 13:38 preloadtrace.log
In messages sind keine Fehlermeldungen. Das ist der Fehler in Firefox wo ich in einem anderen Threed schon mal eine neue Festplatte eingebaut habe.
Es ist nicht die Platte, es ist der RAM. Habe schon zig mal memtest86 über Nacht ausgeführt. Noch nie war ein Speicherfehler aufgetreten. Gestern habe ich auch mal wieder den Kernel compiliert. Hat auch einwandfrei funktioniert.
Heinz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 4. August 2011 20:34:48 schrieb Heinz Dittmar:
df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 128G 45G 84G 35% / devtmpfs 2,0G 304K 2,0G 1% /dev tmpfs 2,0G 2,0G 0 100% /dev/shm /dev/sda3 251M 68M 170M 29% /boot /dev/sda7 256G 101G 156G 40% /home /dev/sda1 40G 18G 22G 45% /windows/C /dev/sda2 20G 4,1G 16G 21% /windows/D
Deine 2GB SharedMem sind voll!
Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm
ls -l /dev/shm insgesamt 1994840 -rw-r--r-- 1 root root 304 4. Aug 10:25 initrd_exports.sh -rw-r--r-- 1 root root 2038714368 4. Aug 13:38 preloadtrace.log
Hier sind die Profis auf der Liste gefragt! Das Log-File scheint ins unermessliche wachsen zu wollen. Mit dem Preload stimmt etwas nicht! Wie sehen die letzten Zeilen des /dev/shm/preloadtrace.log aus? Bitte kopiere das File kurz nach dem Neustart Deiner Maschine irgendwohin und schau Dir die Zeilen genau an! Hier findest Du den Fehler bzw. dessen Herkunft.
Gestern habe ich auch mal wieder den Kernel compiliert. Hat auch einwandfrei funktioniert.
OhOh... und der schreibt alles mit <debug>? Was passiert, wenn Du einen Standard-Kernel benutzt? Das Problem wird vermutlich wie von Geisterhand verschwinden. MfG Th. Moritz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag 04 August 2011 21:38:42 schrieb Thomas Moritz:
Am Donnerstag, 4. August 2011 20:34:48 schrieb Heinz Dittmar:
df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 128G 45G 84G 35% / devtmpfs 2,0G 304K 2,0G 1% /dev tmpfs 2,0G 2,0G 0 100% /dev/shm /dev/sda3 251M 68M 170M 29% /boot /dev/sda7 256G 101G 156G 40% /home /dev/sda1 40G 18G 22G 45% /windows/C /dev/sda2 20G 4,1G 16G 21% /windows/D
Deine 2GB SharedMem sind voll!
Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm
ls -l /dev/shm insgesamt 1994840 -rw-r--r-- 1 root root 304 4. Aug 10:25 initrd_exports.sh -rw-r--r-- 1 root root 2038714368 4. Aug 13:38 preloadtrace.log
Hier sind die Profis auf der Liste gefragt! Das Log-File scheint ins unermessliche wachsen zu wollen. Mit dem Preload stimmt etwas nicht! Wie sehen die letzten Zeilen des /dev/shm/preloadtrace.log aus? Bitte kopiere das File kurz nach dem Neustart Deiner Maschine irgendwohin und schau Dir die Zeilen genau an! Hier findest Du den Fehler bzw. dessen Herkunft. Kann ich erst morgen in Angriff nehmen. Werde auch mal in den Runlevel den boot.preload abschalten, vieleicht hängt es damit zusammen. Dann habe ich noch in /etc/sysconfig/sysctl ENABLE_SYSRQ="192" auf 246 gestellt. Vielleicht sollte hier 0 eintragen.
Gestern habe ich auch mal wieder den Kernel compiliert. Hat auch einwandfrei funktioniert.
OhOh... und der schreibt alles mit <debug>? Was passiert, wenn Du einen Standard-Kernel benutzt? Das Problem wird vermutlich wie von Geisterhand verschwinden. Selbstverständlich benutze ich den Standartkernel. Das diente nur als Mem- Test. uname -a Linux hedi-2.home0.nil 2.6.34.10-0.2-desktop #1 SMP PREEMPT 2011-07-20 18:48:56 +0200 x86_64 x86_64 x86_64 GNU/Linux
Heinz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag 04 August 2011 22:13:10 schrieb Heinz Dittmar:
Am Donnerstag 04 August 2011 21:38:42 schrieb Thomas Moritz:
Am Donnerstag, 4. August 2011 20:34:48 schrieb Heinz Dittmar:
df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 128G 45G 84G 35% / devtmpfs 2,0G 304K 2,0G 1% /dev tmpfs 2,0G 2,0G 0 100% /dev/shm /dev/sda3 251M 68M 170M 29% /boot /dev/sda7 256G 101G 156G 40% /home /dev/sda1 40G 18G 22G 45% /windows/C /dev/sda2 20G 4,1G 16G 21% /windows/D
Deine 2GB SharedMem sind voll!
Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm
ls -l /dev/shm insgesamt 1994840 -rw-r--r-- 1 root root 304 4. Aug 10:25 initrd_exports.sh -rw-r--r-- 1 root root 2038714368 4. Aug 13:38 preloadtrace.log
Hier sind die Profis auf der Liste gefragt! Das Log-File scheint ins unermessliche wachsen zu wollen. Mit dem Preload stimmt etwas nicht! Wie sehen die letzten Zeilen des /dev/shm/preloadtrace.log aus? Bitte kopiere das File kurz nach dem Neustart Deiner Maschine irgendwohin und schau Dir die Zeilen genau an! Hier findest Du den Fehler bzw. dessen Herkunft.
Kann ich erst morgen in Angriff nehmen. Werde auch mal in den Runlevel den boot.preload abschalten, vieleicht hängt es damit zusammen. Ja in den Runlevel boot.startpreload deaktivieren brachte die Lösung. Dann habe ich noch in /etc/sysconfig/sysctl ENABLE_SYSRQ="192" auf 246 gestellt. Vielleicht sollte hier 0 eintragen.
Gestern habe ich auch mal wieder den Kernel compiliert. Hat auch einwandfrei funktioniert.
OhOh... und der schreibt alles mit <debug>? Was passiert, wenn Du einen Standard-Kernel benutzt? Das Problem wird vermutlich wie von Geisterhand verschwinden.
Selbstverständlich benutze ich den Standartkernel. Das diente nur als Mem- Test. uname -a Linux hedi-2.home0.nil 2.6.34.10-0.2-desktop #1 SMP PREEMPT 2011-07-20 18:48:56 +0200 x86_64 x86_64 x86_64 GNU/Linux
Heinz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Friday 05 August 2011 09:24:46 schrieb Heinz Dittmar:
Am Donnerstag 04 August 2011 22:13:10 schrieb Heinz Dittmar:
Am Donnerstag 04 August 2011 21:38:42 schrieb Thomas Moritz:
Am Donnerstag, 4. August 2011 20:34:48 schrieb Heinz Dittmar:
df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 128G 45G 84G 35% / devtmpfs 2,0G 304K 2,0G 1% /dev tmpfs 2,0G 2,0G 0 100% /dev/shm /dev/sda3 251M 68M 170M 29% /boot /dev/sda7 256G 101G 156G 40% /home /dev/sda1 40G 18G 22G 45% /windows/C /dev/sda2 20G 4,1G 16G 21% /windows/D
Deine 2GB SharedMem sind voll!
Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm
ls -l /dev/shm insgesamt 1994840 -rw-r--r-- 1 root root 304 4. Aug 10:25 initrd_exports.sh -rw-r--r-- 1 root root 2038714368 4. Aug 13:38 preloadtrace.log
Hier sind die Profis auf der Liste gefragt! Das Log-File scheint ins unermessliche wachsen zu wollen. Mit dem Preload stimmt etwas nicht! Wie sehen die letzten Zeilen des /dev/shm/preloadtrace.log aus? Bitte kopiere das File kurz nach dem Neustart Deiner Maschine irgendwohin und schau Dir die Zeilen genau an! Hier findest Du den Fehler bzw. dessen Herkunft.
Kann ich erst morgen in Angriff nehmen. Werde auch mal in den Runlevel den boot.preload abschalten, vieleicht hängt es damit zusammen.
Ja in den Runlevel boot.startpreload deaktivieren brachte die Lösung.
...
Heinz
Hallo Heinz, es gibt in /etc/init.d ein Skript namens stoppreload, das bei bei mir als S18stoppreload an das Ende der Reihenfolge der Startskripte in den Runleveln verlinkt ist. Vielleicht war das nicht aktiviert. Tschö, Emil -- -- Registered Linux user since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag 05 August 2011 13:26:45 schrieb Emil Stephan:
Am Friday 05 August 2011 09:24:46 schrieb Heinz Dittmar:
Am Donnerstag 04 August 2011 22:13:10 schrieb Heinz Dittmar:
Am Donnerstag 04 August 2011 21:38:42 schrieb Thomas Moritz:
Am Donnerstag, 4. August 2011 20:34:48 schrieb Heinz Dittmar:
df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 128G 45G 84G 35% / devtmpfs 2,0G 304K 2,0G 1% /dev tmpfs 2,0G 2,0G 0 100% /dev/shm /dev/sda3 251M 68M 170M 29% /boot /dev/sda7 256G 101G 156G 40% /home /dev/sda1 40G 18G 22G 45% /windows/C /dev/sda2 20G 4,1G 16G 21% /windows/D
Deine 2GB SharedMem sind voll!
Wenn die Kiste wieder am Ende ist, zeige bitte den Output von ls -l /dev/shm
ls -l /dev/shm insgesamt 1994840 -rw-r--r-- 1 root root 304 4. Aug 10:25 initrd_exports.sh -rw-r--r-- 1 root root 2038714368 4. Aug 13:38 preloadtrace.log
Hier sind die Profis auf der Liste gefragt! Das Log-File scheint ins unermessliche wachsen zu wollen. Mit dem Preload stimmt etwas nicht! Wie sehen die letzten Zeilen des /dev/shm/preloadtrace.log aus? Bitte kopiere das File kurz nach dem Neustart Deiner Maschine irgendwohin und schau Dir die Zeilen genau an! Hier findest Du den Fehler bzw. dessen Herkunft.
Kann ich erst morgen in Angriff nehmen. Werde auch mal in den Runlevel den boot.preload abschalten, vieleicht hängt es damit zusammen.
Ja in den Runlevel boot.startpreload deaktivieren brachte die Lösung.
...
Heinz
Hallo Heinz, es gibt in /etc/init.d ein Skript namens stoppreload, das bei bei mir als S18stoppreload an das Ende der Reihenfolge der Startskripte in den Runleveln verlinkt ist. Vielleicht war das nicht aktiviert. Ja du hast recht, wenn dann müssen beide aktiviert sein, boot.startpreload und stoppreload der nicht aktiviert war. Darum ist mir /dev/shm voll-gelaufen. Durch den stoppreload wid auch das File preloadtrace.log nach kurzer Zeit wieder gelöscht. Vielen Dank für die Hilfe. Viele Grüße Heinz Dittmar
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
Emil Stephan -
Heinz Dittmar -
Thomas Moritz