Dateien core.13245

[Goslarer1]

Hallo,

ich habe keinerlei Ahnung wohin dieses Tread gehört, da ich die Ursache für denFehler nicht kenne.

Darf aber gerne wenn nötig in das Richtige Forum verschoben werden. :-)

Ich besitze als Hobby einen Server den ich von Alfahosting gemietet habe.

Server: Apache, PHP Version: 5.2.6-1+lenny3, mySQL: 5.0.51a-24+lenny1 in Charset utf-8

Als CMS-System nutze ich das e107-0.7.24

Seit kurzem befinden sich ständig "core.13652" Dateien im Verzeichniss "/html/german/e107_files" und im Verzeichniss "/html/german/"

diese Dateien, core.13652 und haben eine größe von ca.13MB und die CHMOD-Rechte 600, diese werden ständig nach dem löschen wieder angelegt.

core.13652; core.13876; core.13934 usw. hatte schon bis zu 20 dieser Dateien in einem Verzeichniss.

Mein Provider konnte oder wollte mir leider nicht helfen. Und die einschlägigen Foren gaben kaum nennenswerte Ergebnisse.

Angeblich soll es sich bei dieser Datei um eine sogenannte core-Dump-Datei handeln, die durch einen defekten Apachedienst angelegt wird.

Ein sogenanntes Speicherabbild für das betroffene CMS oder der betroffenen Domain die dann auch in den Ordner der Domain abgelegt wird.

Da aber auch andere CMS-Systeme auf ein und dem selben Server betroffen sind, denke ich nicht das es ein Fehler des e107 CMS-Systems ist.

Das diese Dateien von Usern oder vom CMS-System angelegt werden schließe ich aus den CHMOD-Rechten mit 600 aus, zudem auch andere CMS-Systeme betroffen sind.

Kann mir irgendjemand weiterhelfen? Es ist sehr beunruhigend, wenn mann ständig Dateien auf dem Server hat und nicht weiß wodurch und zu welchem Zweck. :-)

Ich Danke.

[Goslarer1]

Ich habe mitlerweile herausgefunden was es mit diesen Dateien aufsich hat. Es ist ein Core -Dump, ein sogenannter Speicherabbild zum Zweck einer Fehlerdiagnose.

Meine Frage ist nun die, wie kann dieser Dienst abgestellt werden? Das er abgestellt werden kann weiß ich mittlerweile, nur nicht wo und wie.

[Goslarer1]

Was diese Core Dateien sind und zu welchem Zweck, das habe ich mittlerweile herausgefunden.

Aber wie diese ausgewertet werden leider nicht.

Kann mir jemand bei der Auswertung helfen?

Währe sehr Nett. Danke

Gruß

[darkfader]

Hi Du,

Was diese Core Dateien sind und zu welchem Zweck, das habe ich mittlerweile herausgefunden.

Aber wie diese ausgewertet werden leider nicht.

Kann mir jemand bei der Auswertung helfen?

Währe sehr Nett. Danke

Gruß

also Coredumps zu analysieren ist an sich etwas fuer Programmierer, aber das koennen wir uns zumindest kurz anschauen.

Erstmal aber noch die Antwort auf Deine ersten Fragen:

- coredumps werden automatisch vom System erzeugt, wenn ein Prozess in eine Ausnahmesituation lief (Fehler in der Speicherverwaltung des Prozess, kaputte Library geladen, oder was auch sonst unerwartet war)

- bei manchen unixen kann man diese funktion auf kernelseite richtig an/ausschalten, bei manchen nicht. was immer geht, ist das schreiben des dumps abzuschalten.

- dafuer - und als sicherheitseinstellung - gibt es eine "quota", die die groesse von coredumps einschraenkt. man kann so z.b. sagen, jede anwendung kann einen schreiben, aber er darf nur 1MB gross werden.

- wenn man dann genauer gucken will, kann man den wert wieder hochdrehen.

- diese einstellung ist ein sogenanntes "ulimit"

Die kannst Du Dir alle mit

ulimit -a anschauen, gleich das erste ist unseres:

waxu0024:~# ulimit -a

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

0 heisst "0 blocks maxmail" damit also "aus" (ein block kann unterschiedlich gross sein, je nachdem wie die platte formatiert ist, aber egal)

Damit ist es also erstmal ausgeschaltet.

ausserdem noch interessant;

waxu0024:~# sysctl -a | grep core

error: permission denied on key 'net.ipv4.route.flush'

kernel.core_uses_pid = 0

kernel.core_pattern = core

diese beiden stellen ein, dass die coredumps mit "core" anfangen sollen und ob hinter core. die prozess ID mitkommt oder nicht. Bei nem Prozess der andauernd startet..., stirbt..., startet... macht diese Einstellung natuerlich nen Unterschied, weil dann unter Umstaenden hunderte oder tausende Cores entstehen koennen. Dann ist auch 1MB schon zu gross.

Was noch wichtig ist, so ein core wird immer im Start, bzw. Arbeitsverzeichnis eines Prozesses geschrieben.

Das kann auch spannende Folgen haben - der Apache stirbt da, wo die Websites liegen. Ein Samba stirbt u.U. in /etc/init.d wo sein Startscript war. Und gewaltig aufpassen sollte man mit Zeug wie webbrowsern oder grossen dicken Datenbanken, oder Filesystemtreiber, die dann ggf. ein paar GB dumpen. Ganz spitze.

Deswegen als Admin nie was in rootverzeichnis etc. starten, sondern besser nach /tmp wechslen und dann mit Pfad aufrufen. Ansonsten schiesst man mal unerwartet das root oder var voll und kann dann mit spannenden Problemen kaempfen.

soweit mal dazu, ulimit -c 0 ist also fuer Deinen apache vermutlich das richtige. Wo Du ein ulimit setzen kannst, darfst selber googlen

Man kann sie so stellen, dass es alle erwischt, oder nur einzelne user.

Das limit gilt fuer einen ab dem Zeitpunkt, wo es gelesen wird.

d.h. wenn es in einer globalen konfigdatei steht, fuer jeden prozess danach. wenn Du es in der shell eintippst, nur fuer Dich, in der einen session. (glaub ich)

so, zum anschauen des dumps:

1. schritt: gucken, welches programm schuld war:

file <corefile>

dann steht da "coredump from apache" oder so

2. schritt:

gucken, ob das programm denn noch laeuft oder nun die website tot ist

3. schritt

mit "gdb" (gnu debugger) kannst Du nachschauen, was das programm zu letzt gemacht hat. als admin interessiert einen da eigentlich nur eine ansicht der letzten paar aktionen, ich glaub, das nennt man normal dann auch stacktrace.

probier es mal:

gdb /pfad/zum/apache/binary /pfad/zum/corefile

der debugger vergleicht nun sozusagen das original mit dem absturz.

jetzt kannst einfach "bt" eingeben und gucken, ob da was steht, was Dir weiterhilft.

Ich guck da normal nach den letzten treibern oder funktionen, die noch aufgerufen wurden.

Aber - mehr als 3-4 mal pro Jahr muss man das als Admin eigentlich nicht machen. Und Du solltest mal einfach ins apache error_log gucken, weil da bestimmt eins der module kaputt ist, oder das ram zu knapp.

Gruesse,

Flo

Bearbeitet 10. März 2011 von darkfader
warum man nur in /tmp apps laufen laesst und noch ein grund icht als root zu surfen