Mein Redhat-Server stürzt alle drei Wochen etwa sonntags um 4:15 Uhr ab. (Nun, es war sonntags, die letzten beiden waren donnerstags um 4:15 Uhr.) Wenn man sich die Protokolle ansieht (MySQL, HTTPD, Nachrichten), gibt es keine Hinweise darauf, warum. Sie scheinen einfach aufzuhören.
Ich habe ein kleines Skript ausgeführt, um alle 15 Minuten den Speicher auszulesen, und auch dieses stoppt (bei normalen Messwerten) zu diesem Zeitpunkt.
Der Server steht remote bei einem Provider, daher kann ich nur über das Web darauf zugreifen. Ich verwende Plesk.
Es scheint, dass ein festgelegter Job oder etwas anderes das Problem verursacht. Ich kann in der Crontab nichts sehen.
Meine Frage lautet also: Hat das schon mal jemand gehabt und kann Ratschläge geben? Falls nicht.
Kennt jemand eine Möglichkeit, detailliertere Protokolle zu erhalten als die, die die Nachrichtendatei bietet? Ich dachte an ein Aufzeichnungsprogramm im Blackbox-Stil oder vielleicht an etwas so Einfaches wie eine Option irgendwo, um den Umfang der Berichte im Nachrichtenprotokoll zu erhöhen.
Danke
Antwort1
Dies sind die Zeiten, zu denen cron.daily-Jobs geplant sind. Ich würde also in /etc/cron.daily oder weekly oder monthly nachsehen, da die ersten Verdächtigen
Sie können installieren, auf dem alle 10 Minuten ein Snapshot der Prozesse aufgezeichnet wird
Alternativ können Sie psacct installieren und accton und lastcomm verwenden, um zu sehen, was ausgeführt wurde
das Einschalten von Auditing ist auch eine Option, siehe auditd(8)
Antwort2
Sie können Core Dumps aktivieren, die den Systemspeicher in eine Datei kopieren, wenn ein Server abstürzt.
Das nächste Problem besteht darin, was mit der Coredump-Datei zu tun ist. Wenn Sie jemanden kennen, der sich mit GDB auskennt, kann er vielleicht etwas dagegen tun. Oder Sie können den Befehl „Strings“ verwenden, um den gesamten Text aus der Coredump-Datei zu löschen, und vielleicht finden Sie etwas.
Antwort3
Melden Sie sich auf einer anderen Box an, die über eine gute Verbindung verfügt, führen Sie „screen“ aus, melden Sie sich per SSH beim Server an und verfolgen Sie kern.log, daemon.log, syslog und Meldungen in den einzelnen Bildschirmfenstern. (Strg-A, C zum Erstellen eines neuen Fensters, Strg-A, D zum Trennen, screen -r zum Fortsetzen)
Wenn der Server erneut abstürzt, sollten Sie das Ende der Protokolle in Ihrer Bildschirmsitzung haben, auch wenn diese beim Absturz der Maschine nicht ordnungsgemäß auf die Festplatte geschrieben wurden.
Wenn Sie einen Kernel Panic oder Oops vermuten
kernel.panic=5 kernel.panic_on_oops=5
in Ihrer sysctl.conf oder einer gleichwertigen Datei wartet 5 Sekunden, ermöglicht möglicherweise das Leeren der Laufwerke und führt dann einen Neustart durch.