Ein Server aus dem Monitoring geflogen

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von mare, 12. Mai 2011.

  1. mare

    mare Member

    Hallo,

    Wir haben ein Setup mit einem ISPC-Master und 4 Workern.
    Jetzt ist mir aufgefallen, das einer der Worker keine Systemdaten mehr bringt. (Auslastung / Platten / UPdatestand) Seine Jobs holt er aber und verarbeitet diese auch.

    Ich muß auch zugeben, dass ich vor einigen Tagen am Mysqlserver des Hosts gebastelt habe um die Option eine innodb per File zu aktivieren und dabei alle Datenbank einmal raus und wieder reingeschoben habe.

    Wo / Wie kann ich da ansetzen.

    ISPC 3.0.3.3

    /mare
     
    Zuletzt bearbeitet: 12. Mai 2011
  2. Till

    Till Administrator

    Möglicherweise fehlen die Schreibberechtigungen für diesen slave für die monitor_data Tabelle im master server. Versuch Dich mal mit den Zugangsdaten aus der config.inc.php Datei vom slave aus in den master einzuloggen und dann einen Datensatz in die "monitor_data" Tabelle zu schreiben.

    Falls dass ads problem ist, kannst Du die Rechte entweder manuell reparieren oder aber Du frst das ispconfig update.php script auf dem master aus und wählst dabei aus dass er die Rechte in der mysql DB neu konfigurieren soll.
     
  3. mare

    mare Member

    Hi,

    Das Einloggen funktioniert und schreiben kann ich mit dem Account auch...
     
  4. Till

    Till Administrator

    Schalte mal debugging für den slave ein und ruf dann das server.sh script mal manuell auf, ob Du da irgendwelche Fehlermeldungen bekommst.
     
  5. mare

    mare Member

    <schei****>
    und ich war mir sicher, das die Aufgaben verarbeitet werden.
    </*******>

    12.05.2011-15:38 - DEBUG - There is already an instance of server.php running. Exiting.

    ps ax | grep server.php | awk {'print "kill "$1'} | sh :rolleyes:



    Danke für die Mühe.
     
  6. mare

    mare Member

    hmm.

    so ganz scheint es das noch nicht gewesen zu sein ..
    Nach ein Paar Minuten ist der server.sh Przess wieder hängengeblieben.

    Ich lasse es jetzt mal mit Debug weiterlaufen.
     
  7. Till

    Till Administrator

    Kommentier mal den cron aus, dann kill den bestehenden prozess und ruf ihn danach manuell auf (musst ggf. das locfile im ispconfig temp folder löschen). Dann sollte an sich irgendeine Fehlermeldung zu sehen sein warum das Script hängen bleibt. Hast Du vielleicht ein ispconfig update für den slave über die ispconfig Oberfläche gestartet?
     
  8. mare

    mare Member

    Hallo Till,
    Danke für deine Mühe.
    Ich habe mir den Server mal angeschaut.
    Vor kurzem ist das fastcgi "übergelaufen" und der Server hat einen Kernel UUUPS gemacht. Seit dem ist auch der SNMP hängengeblieben. Ich habe das System jetzt rebootet und momentan sieht alles wieder gut aus.

    Fastcgi und der Googlebot haben eine Webapp dazu bewegt komplette 8GB RAM zu belegen und als dann der swap zu war, war aus die Maus.

    Ich habe jetzt das mod_fcgi angepasst. Das steht per default glaub ich auf 1000 Prozesse * ca 24 MB RAM = :eek:


    Wenn hier einer Updates macht ..... dann bin ich das :D
     
  9. Till

    Till Administrator

    So war das nicht gemeint :) Aber updates die über das Webinterface gestarte werden können manchmal hängen. Das Problem wird erst mit ISPConfig 3.0.4 gänzlich behoben sein, da der update Mechanismus für Updates über das Interfae neu geschrieben wurde. Daher updates im Moment noch am besten auf der Shell einspielen.
     
  10. mare

    mare Member

    Ich weiß, war ja auch nur Spaß :cool:

    Übers WebIF kann ich eh erst updaten, wenn meine Änderungen automatisch als diff gegen die vanilla Version ein Patchfile erzeugen, was dann gleich noch patch Befehl eingespielt wird. *fg*
     

Diese Seite empfehlen