oom-killer Problem

[Hygrom]

Hallo

Ich habe bei einem Rechner ein oom-Problem.
Der Rechner ist bei einem Kunden verbaut, und zwar hinter einer Blende, wo man nicht ohne weiteres ans Gerät kommt. Zudem ist er auch in einer entfernteren Stadt. Zugriff erfolgt über SSH.
Es handelt sich um einen MiniPC mit CF-Karte als Speichermedium, also keine Festplatte.

auf dem System läuft Debian 6.0.2 Squeeze Kernel 2.6.32-5-686

Es läuft als Desktop-System nur Xserver mit Fluxbox.
über die .fluxbox/startup wird nach dem automatischen Einloggen via rungetty iceweasel im Kiosk-Modus (mit autohide-Addon) gestartet.
Schon wenige Wochen nach dem Einbau fängt der Rechner sporadisch an, den Iceweasel-Prozess zu killen.

Das habe ich den Infos aus der syslog entnommen. Er zeigt auf dem Monitor einfach nur den Dekstop-Hintergrund an.
Wenn man ein paar mal neu startet, fährt der PC irgendwann wieder komplett hoch, mit iceweasel.

Die Frage ist, warum er das tut. Es sind schon einige Dutzend solcher Rechner bei Kunden verbaut. Die Software wurde von einem Image per dd aufgespielt, so dass auf allen Rechnern nahezu identische Betriebssysteme laufen.

Ich vermute ja einen Fehlerhaften Speicher, aber ich weis nicht ob es das RAM oder die CF-Karte ist.

Wie finde ich das am besten heraus?
Gibt es eine Möglichkeit, das softwareseitig zu lösen, ohne Teile des Gerätes tauschen zu müssen?

Ich bin in Linux noch nicht sehr bewandert, bitte daher um Nachsicht.

Ich poste hier mal Auszüge der syslog, die relevant scheinen. Ich danke für eure Hilfe.

 36318

[Meillo]

Dateiauszuege dieser Groesse gehoeren ins NoPaste. Bitte aendere deinen Beitrag.


Edit: Sehr schoen, danke.

[niemand]

Ich vermute ja einen Fehlerhaften Speicher, aber ich weis nicht ob es das RAM oder die CF-Karte ist.

Nicht fehlerhaft, sondern schlicht voll. Und nicht Massenspeicher, sondern RAM. Iceweasel/FF ist nicht der geeignetste Browser für die Ausstattung der Maschine, und kann unter bestimmten Umständen weit mehr RAM brauchen, als dort zur Verfügung steht. Ob diese Umstände zutreffen, lässt sich mangels Wissen um die Umstände von hier aus nicht beurteilen.

cu,
niemand

[Hygrom]

Hm, also wie gesagt haben wir einige Dutzend dieser Rechner im Einsatz, bei denen läuft überall die selbe Software auf der selben Hardware. Bis auf geringe Modifikationen (Wlan statt Kabel z.B.) und nur dieser Rechner macht Probleme. Beim Kunden hängt ein weiterer dieser PC im Netz, der die gleiche Arbeit macht und der hat keine Speicherprobleme.
Im Betrieb mit Iceweasel ergibt free folgende Ausgabe ( der PC läuft seit 10 Stunden):

Mem total: 2019
Used: 270
free: 1749

Ich kann mir nicht vorstellen, dass iceweasel direkt beim Start die 2GiG Speichergrenze knackt, wenn es aber 10 Stunden läuft, noch 1,7 GB frei sind.Ich bin wie gesagt kein Profi in Linux, aber mir erschließt sich da kein Sinn drin. Daher dachte ich an defekten RAM der nur den Fehler produziert, wenn die Daten zufällig eine Defekte Zelle treffen.

Was benötigt ihr denn noch für Infos um mir helfen zu können?

[niemand]

Was benötigt ihr denn noch für Infos um mir helfen zu können?

Infos über den Rechner an sich wären mal nicht schlecht. Und du könntest den Speicherverbrauch nach Prozessen sortiert loggen, wodurch schnell klarwerden sollte, welcher Prozess vor dem Einspringen des oom-Killers den Speicher frisst.

Sowohl deine Ausgabe, als auch das Log selbst deuten nicht unbedingt auf 2GB hin. 'free' gibt ohne weitere Angaben kB aus (wobei 270kB für ein laufendes System irgendwie unrealistisch ist. Optimalerweise die kompletten Aufruf und Ausgabe in code-Tags posten, das vermeidet Missverständnisse).

Der oom (Out Of Memory)-Killer kommt dann ins Spiel, wenn eben der Speicher voll ist. Defektes RAM äußert sich meist anders (namentlich in Form zufälligen Segfaults und unerklärbaren Abstürzen).

Edit: Wenn es nicht zuviele Umstände macht, wäre auch der Bereich vom Start bis etwa eine Sekunde danach aus dem syslog von Interesse (bitte wieder nach NoPaste).

cu,
niemand

[Hygrom]

Ok, vielen Dank für die Hilfe
Hier einige Angaben:

Free-Aufruf:

Code: Alles auswählen

:~ free -m
             total       used       free     shared    buffers     cached
Mem:          2019        270       1749          0         13         79
-/+ buffers/cache:        177       1842
Swap:          227          0        227


df-Aufruf:

Code: Alles auswählen

:~ df -h
Dateisystem          Größe Benut  Verf Ben% Eingehängt auf
/dev/sda2             1,7G  1,2G  494M  71% /
tmpfs                1010M     0 1010M   0% /lib/init/rw
udev                   10M  668K  9,4M   7% /dev
tmpfs                1010M     0 1010M   0% /dev/shm


Der Rechner ist ein Minipc 616 von Concept-International:
http://www.concept.biz/de/produkte/mini-pc/minipc-616.html
mit 2GB RAM und 2 GB CF-Karte und Intel ATOM 1,6 GHz

Syslog der ersten Sekunde.
 36319

Speicherverbrauch nach Prozessen sortiert loggen

Was meinst Du genau? Leider reicht meine Kenntnis an dieser Stelle nicht. Welchen Befehl, bzw. welche Datei ist damit gemeint?

Vielleicht die Ausgabe von top?:

Code: Alles auswählen

top - 16:00:17 up  5:49,  3 users,  load average: 0.01, 0.01, 0.00
Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.8%us,  0.8%sy,  0.0%ni, 98.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1025172k total,   213000k used,   812172k free,     9656k buffers
Swap:   232932k total,        0k used,   232932k free,   148216k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                           
 1444 mssuser   20   0  140m  38m  18m S    2  3.8   7:22.62 firefox-bin                                                                                       
 1390 root      20   0 48156 8516 3624 S    1  0.8   3:21.86 Xorg                                                                                             
 3175 root      20   0  2436 1144  896 R    0  0.1   0:00.06 top                                                                                               
    1 root      20   0  2032  704  612 S    0  0.1   0:01.35 init                                                                                             
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                         
    3 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                       
    4 root      20   0     0    0    0 S    0  0.0   0:00.02 ksoftirqd/0                                                                                       
    5 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                       
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                                       
    7 root      20   0     0    0    0 S    0  0.0   0:00.08 ksoftirqd/1                                                                                       
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1                                                                                       
    9 root      20   0     0    0    0 S    0  0.0   0:00.18 events/0           

EDIT:
Oha mir fällt etwas auf.

der "free" - Aufruf oben ist von dem 2. Rechner, da der heute länger lief, und ich die Speicherauslastung von einem Rechner anzeigen wollte, der heute etwas länger in Betrieb war.
Bei der ausgabe von "top" viel mir auf, dass in dem Problemrechner anscheinend nur 1 GB verbaut ist.

Daher hier nochmal die Ausgabe von free auf dem Problemrechner:

Code: Alles auswählen

:~ free -m
             total       used       free     shared    buffers     cached
Mem:          1001        255        745          0          9        192
-/+ buffers/cache:         53        947
Swap:          227          0        227


Trotzdem ist der Großteil des Speichers im laufenden Betrieb frei und nichtmal die SWAP-Partition wird benutzt.
Die Frage, warum der PC ab und an beim Starten den Speicher vollschreibt, bleibt also bestehen. In den meisten Fällen verhält er sich ja auch normal. Der Fehler tritt alle 1-2 Wochen auf.

Der PC zeigt die ganze Zeit übrigens nur eine Vollbild-Webseite an, die lokal gespeichert ist und einige (3-6) JPG als Javascript-Slideshow ausgibt.
Mehr passiertda nicht.

[niemand]

Irgendwas passt da nicht:

Code: Alles auswählen

Memory: 1013220k/1040128k available

im Vergleich zu deiner Ausgabe von 'free -m'. Damit kann ich gerade nicht viel anfangen. Magst du mal den Inhalt von /proc/meminfo posten?

Was das Loggen angeht: ich würde mir ein kleines Script schreiben, das die Ausgabe von 'top -b' parst und die Infos (Prozess, der gerade den meisten Speicher braucht) in eine Datei schreibt. Gibt sicher elegantere Methoden, vielleicht schreibt noch jemand was dazu.

cu,
niemand

[Hygrom]

Hier der Inhalt von /proc/meminfo
Wie im EDIT gesagt, ist mir das auch gerade aufgefallen, dass dort nur 1GB verbaut ist.
Im laufenden Betrieb ist der Speicher aber trotzdem 3/4 frei.
Kann es denn sein, dass beim Booten über 1GB geladen wird, und dann bis auf 250MB alles wieder gelöscht wird?

Code: Alles auswählen

MemTotal:        1025172 kB
MemFree:          786220 kB
Buffers:            9728 kB
Cached:           173204 kB
SwapCached:            0 kB
Active:            71904 kB
Inactive:         147416 kB
Active(anon):      36568 kB
Inactive(anon):    71704 kB
Active(file):      35336 kB
Inactive(file):    75712 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:        134920 kB
HighFree:            224 kB
LowTotal:         890252 kB
LowFree:          785996 kB
SwapTotal:        232932 kB
SwapFree:         232932 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:         36464 kB
Mapped:            27064 kB
Shmem:             71880 kB
Slab:               9928 kB
SReclaimable:       4056 kB
SUnreclaim:         5872 kB
KernelStack:         744 kB
PageTables:          788 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      745516 kB
Committed_AS:     236304 kB
VmallocTotal:     122880 kB
VmallocUsed:       10060 kB
VmallocChunk:      83956 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       4096 kB
DirectMap4k:      905208 kB
DirectMap4M:           0 kB


[niemand]

Im laufenden Betrieb ist der Speicher aber trotzdem 3/4 frei.

Interessant ist, was direkt vor dem Anfordern des oom-Killers passiert. Bei heutigen Speicheranbindungen ist ein GB in weniger als einer Sekunde voll. Dass der Speicher zu dem Zeitpunkt belegt ist, steht außer Frage. Die Frage ist, welcher Prozess genau dafür verantwortlich ist – und was ihn dazu veranlasst. Deswegen → loggen, und anschließend nachsehen.

cu,
niemand

[CrashMan]

Wenn der oom-killer bei mir anschlägt, dann gibt dmesg auch eine Liste der laufenden Prozesse aus

Code: Alles auswählen

[222834.713406] firefox-bin invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
...
[222834.727295] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
[222834.727305] [ 1196]     0  1196     5417      220   1     -17         -1000 udevd
[222834.727311] [ 2099]     0  2099     4738       65   1       0             0 rpcbind
[222834.727316] [ 2119]   109  2119     6349      115   1       0             0 rpc.statd
[222834.727320] [ 2293]     0  2293    29712      326   1       0             0 rsyslogd
[222834.727325] [ 2312]   101  2312     8309     2284   0       0             0 dbus-daemon
[222834.727330] [ 2321]     0  2321    41130      415   0       0             0 NetworkManager
und so weiter...
[222834.727677] Out of memory: Kill process 27171 (firefox-bin) score 120 or sacrifice child
[222834.727685] Killed process 27171 (firefox-bin) total-vm:1039700kB, anon-rss:367532kB, file-rss:3560kB


Ich weiß nun nicht, inwiefern man das vielleicht erst aktivieren muss, aber denke, dass eine solche Ausgabe hier helfen könnte.

mfg

[Hygrom]

Erstmal vielen Dank für die Ideen.
Ob ich es hinbekomme, ein Skript zu erstellen, das beim Booten den Speicherverbrauch mitloggt, weis ich noch nicht.

Aber die Ausgabe von dmesg werde ich jetzt zuerst mal testen.

Im schlimmsten Fall müssen wir das Gerät wohl ausbauen und einen 2GB Riegel einbauen. Aber das ist wirklich eine Mordsarbeit die ich erstmal umgehen will.
Sollten beim Booten aber wirklich nur vitale Daten geladen werden, die über 1GB verbrauchen, und erst danach wieder verschwinden, gibt es wohl keinen anderen Weg.

Ich melde mich später wieder dazu.

EDIT:
Die dmesg logs vom letztem Mal reichen nicht bis zum Zeitpunkt wo oom-killer seinen Einsatz durchzieht.
Und der Fehler tritt so sporadisch auf, dass ich jetzt abwarten muss.

Ich hab jetzt aber folgende Idee. Der oom-killer hat bisher immer den firefox-bin - Prozess, also Iceweasel, gekillt. Und zwar so 80 Sekunden nach dem Start. Es scheint so, dass Debian hochfährt, dann X und Fluxbox startet, und dann startet Iceweasel und verbraucht beim Starten manchmal so viel Speicher, dass der oom-Killer erscheint und ihn kaltblütig killt.
Auf dem Monitor ist dann immer der Desktop mit dem Firmenlogo als Background zu sehen.

Ich würde jetzt ein Bash-Script alle paar Minuten per ps -A nach dem Firefox-bin - Prozess suchen lassen. Wenn der nicht gefunden wird startet es ihn mittels su -c "iceweasel URL xxxx -fullscreen --display=:0.0" user.
Ansonsten soll sich nix tun.

Wäre das eine sinnvolle Lösung? Oder birgt sie Gefahren?