.sh Script zum automatisch "shutdown -rn now"

[xamibor]

hi,

ich habe das Problem das sich manchmal die mysql verabsciedet. der Befehl rcmaysql restart /start hat keine wirkung. erst wenn ich des komplette System reboote kann ich erts wieder die Mysql DB starten.

das sich eine nicht unwichtige seite auf dem Server befindet habe ich mir überlegt ein scrit zuschreiben das in einem intervall von 5 Minuten (Cron) prüft ob die Mysql Db zu erreichen ist.
Ist sie nicht zu erreichen solle er den Server rebooten, und mir eine Mail schicken das die DB nicht zuerreichen war.

Hat jemand eine idee wie so ein .sh script aussehen kann?

lg
Andreas

[captaincrunch]

Ein solches Script ist das geringste Problem. Sinniger wäre allerdings, das Grundproblem anzugehen, statt mit Flickschusterei anzufangen (gerade wenn die Seite nicht "unwichtig" ist.

[xamibor]

Ja ich gebe dir recht!

nur momentan fehlt mir die Zeit und villeicht auch das wissen es raus zubekommen :-(

bis ich die sache gefunden habe sehe ich keinen andere Möglichkeit.

Das Problem:
Die MySQL DB verabschiedet sich in unregelmäßigen Abständen....
Log Files haben nach meinem eigeenen Wissenstand bisher keine ergebenise gebracht.

lg
Andreas

[captaincrunch]

Beobachte doch einfach mal, ob bei einem "/etc/init.d/mysql stop" noch mysql-Prozesse weiterlaufen. Wenn's mehr nicht ist, kann man die ganz einfach per Script abschiessen, dann würdest du dir das ständige rebooten (was der ohnehin recht empfindlichen Platte im Rootie) sowieso nicht gut tut.

[xamibor]

wenn ich nach einem "absturz" ps fax oder ps fax | grep mysql eingebe zeigt er mir nichts an.

lg
Andreas

[dea]

wenn ich nach einem "absturz" ps fax oder ps fax | grep mysql eingebe zeigt er mir nichts an.

Naja - "nichts" ist reichlich ungenau. Angenommen, Du meinst damit, keine mysql* Prozesse erkennen zu können, dann würde das bedeuten, dass sich die DB komplett verabschiedet hat. Wenn dann ein "rcmysql [re]start" und ein "/etc/init.d/mysql [force-]restart" auch nichts bringen sollten wäre es angebracht, anhand der ursprünglichen PID (in Debian unter /var/run/mysql/ zu finden) die Suche zu intensivieren. Erfolgversprechend könnte sich auch die Suche nach Zombies (Prozesse ohne PPID bzw. Userland-Prozesse mit PPID 1) gestalten. Auf jeden Fall würde ich die mysql tracen, um so zumindest Informationen bis kurz vor dem Abgang zu erhalten (augescheinlich hat sie nicht mal mehr die Möglichkeit, die Logs fertig zu schreiben), da es sich mit großer Wahrscheinlichkeit um einen Anwendungsfehler handelt.

[xamibor]

wie macht man das?

mysql tracen,

wie würde der genaue Befehl aussehen um das rauszufinden? ..

Erfolgversprechend könnte sich auch die Suche nach Zombies (Prozesse ohne PPID bzw. Userland-Prozesse mit PPID 1) gestalten

ich meinte natürlich speziell auf den prozess mysql :-)

Wahrscheinlichkeit um einen Anwendungsfehler handelt

nun es läuft ein phpnuke system und ich habe es zu fast 80% angepasst .... bis vor kurzem war es keine Problem ... ich habe vor dem ersten absturz keine besonderen arbeiten dran gemacht.

kann so was auch von aussen ... hack angriff ... kommen?

lg
Andreas

[captaincrunch]

kann so was auch von aussen ... hack angriff ... kommen?

Da das kleine Wörtchen "phpnuke" ja schon gefallen ist, ist genau diese Möglichkeit nicht auszuschließen. ;)

[dea]

wie macht man das?

mysql tracen,

wie würde der genaue Befehl aussehen um das rauszufinden? ..

Kann ich Dir leider nicht sagen, da ich speziell von mysql keine Ahnung habe. Aber die Doku auf mysql.com sollte Dir weiterhelfen (oder das DB-Brett hier *g*)

Erfolgversprechend könnte sich auch die Suche nach Zombies (Prozesse ohne PPID bzw. Userland-Prozesse mit PPID 1) gestalten

ich meinte natürlich speziell auf den prozess mysql :-)

AFAIK laufen auch unter mysql einige Tochterprozesse, sicher bin ich mir allerdings nicht. Du kannst ja mal ein "pstree -np <mysql-PID>" bei ordnungsgemäß laufender DB veranstalten, dass hast Du sogar noch eine nette grafische Ã?bersicht.

Wahrscheinlichkeit um einen Anwendungsfehler handelt

nun es läuft ein phpnuke system und ich habe es zu fast 80% angepasst .... bis vor kurzem war es keine Problem ... ich habe vor dem ersten absturz keine besonderen arbeiten dran gemacht.

kann so was auch von aussen ... hack angriff ... kommen?

Klärchen, auch das kann sein. Aber ich würde zunächst in den eigenen Topf schauen und beispielsweise nach Tippfehlern suchen ;) Sehr beliebt, sowas. Wenn Du das mit dem Tracen hinbekommen hast, wirst Du sicherlich auch zusätzliche, wertvolle Informationen erhalten die Dir die Unterscheidung zwischen "Selber Schuld" und "Böser Junge" erleichtern (wobei der Einsatz eines *nukes imho schon "Selber Schuld genug ist).

Hast Du eigentlich schon überprüft, ob Deine Versionen von mysql, PHP, *nuke, etc. pp. aktuell sind bzw. ob es in der Vergangenheit Patches/Upates gab?