.ispconfig_lock bleibt stehen

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von osterhase, 10. Juli 2012.

  1. osterhase

    osterhase New Member

    Hallo!

    Folgendes Problem: Wenn die server.sh als cronjob ausgeführt wird (und auch händisch) bleibt die .ispconfig_lock bestehen und wird auch nicht gelöscht. Im ersten Anlauf beim Ausführen über die Konsole kommt trotz Debug-Level 0 in der config.inc.php nix zurück (weder in der Weboberfläche noch in den Log-Files).

    ps ax zeigt das da was hängen geblieben ist:
    Code:
    17633 ?        Ss     0:00 /usr/lib/cgi-bin/php -d magic_quotes_gpc=off -d session.save_path=/usr/local/ispconfig/server/temp
    17635 ?        S      0:00 /usr/lib/cgi-bin/php -d magic_quotes_gpc=off -d session.save_path=/usr/local/ispconfig/server/temp
    17695 pts/2    S+     0:00 tail -f /var/log/ispconfig/cron.log
    17738 ?        Ss     0:00 /bin/sh -c /usr/local/ispconfig/server/server.sh > /dev/null 2>> /var/log/ispconfig/cron.log
    17741 ?        S      0:00 /bin/sh /usr/local/ispconfig/server/server.sh
    17749 ?        S      0:00 /usr/bin/php -q /usr/local/ispconfig/server/server.php
    18589 ?        Ss     0:00 /bin/sh -c /usr/local/ispconfig/server/server.sh > /dev/null 2>> /var/log/ispconfig/cron.log
    18592 ?        S      0:00 /bin/sh /usr/local/ispconfig/server/server.sh
    18599 ?        S      0:00 /usr/bin/php -q /usr/local/ispconfig/server/server.php
    
    Habe schon probiert das Ganze händisch alles zu löschen bzw. die Prozesse zu beenden. Alles leider ohne Erfolg.

    Als zweites Problem werden die Protokolldateien in der Weboberfläche von ISPConfig nicht mehr aktualisiert, aber ich denke das hängt mit diesem Problem zusammen (?).

    Ich weiß wirklich nicht mehr weiter und bin für jede Hilfe dankbar.

    Viele Grüße

    ISPConfig 3.0.4.6 (Multiserver-Setup), Debian
     
  2. Till

    Till Administrator

    Wahrcsheinlich ist irgend etwas in Deiner php.ini falsch eingestellt so dass der PHP prozess abbricht. Häufige Fehler sind:

    - Es wurden irgendwelche Funktionen, insbesondere Shell Funktionen, in der cli php.ini deaktiviert.
    - Der Speicher für php ist zu klein oder es wurde das M für Megabytes vergessen. 128 = 128 bytes während 128M = 128 Megabytes.
    - Es wurde ein instabiles php Plugin instaliert, ein gängiger kandidat für Instabilitäten ist eaccelerator. Xcache macht hingegen nie Probleme.

    Ja.
     
  3. osterhase

    osterhase New Member

    Vielen Dank für die Antwort - ich bin auf ein relativ krudes Rechteproblem im /tmp-Ordner gestoßen, was allerdings unabhängig von ISPConfig war.

    In der php.ini wurden keine Änderungen vorgenommen. Das Memory-Limit ist auch korrekt gesetzt. Plugins wurden keine nachgeladen. Würde eine Neuinstallation von php helfen? Der Server ist produktiv...

    Was mich arg verwundert ist, das keine Logs geschrieben werden - gucke ich an der falschen Stelle? Die php-Prozesse werden ja irgendwie auch nicht abgebrochen. Zumindest bleiben sie als Prozess bestehen.

    Nachtrag:
    Das einzige was mir in der php.ini aufgefallen ist, ist das:

    magic_quotes_gpc = Off
    magic_quotes_runtime = Off
    magic_quotes_sybase = Off

    Korrekt so?
     
    Zuletzt bearbeitet: 11. Juli 2012
  4. Till

    Till Administrator

    Eine Neuinstallation von PHP wird wahrscheinlich nicht helfen. Hast Du eaccelarator installiert?

    das ist ok so, die Einstellungen sind für shellscripte sowieso nicht relevant.

    Schau mal in die FAQ, dort steht wie Du Dein problem debuggen kannst:

    Debugging of ISPConfig 3 server actions in case of a failure « FAQforge
     
  5. osterhase

    osterhase New Member

    Danke für die schnelle Antwort. Dachte irgendwie ich müsste das mit dem Logging hart in der config umstellen... jetzt sehe ich immerhin wieder was.

    (Cronjob deaktiviert)
    Nach Aufruf der server.sh:
    Code:
    11.07.2012-12:54 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
    11.07.2012-12:54 - DEBUG - No Updated records found, starting only the core.
    11.07.2012-12:54 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
    Läuft alles super durch.
    Dann bleibt's allerdings eine Minute später wieder stehen.
    Code:
    11.07.2012-12:55 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
    11.07.2012-12:55 - DEBUG - No Updated records found, starting only the core.
    eaccelarator habe ich nicht installiert soweit ich weiß.

    Nachtrag:
    Die Logs in der Weboberfläche werden übrigens trotz händischem erfolgreichem Durchlauf nicht aktualisiert.
     
    Zuletzt bearbeitet: 11. Juli 2012
  6. osterhase

    osterhase New Member

    Weitere Nachträge:
    - eaccelarator ist nicht installiert
    - trotz erhöhtem php-Loglevel wird nichts in die Logs geschrieben, Prozess bleibt unkommentiert stehen

    Beobachtung: Händisch angestartet bleibt er immer bei vollen 5 Minuten oder vollen 10 Minuten stehen :confused:

    Jemand noch nen heißen Tipp?
     
  7. Till

    Till Administrator

    Dann hätte das wohl in der FAQ gestanden..

    Ok, dann hängt bei Dir also eines der Programme die ausschließlich vom Monitor aufgerufen werden. Hast Du in letzter zeit irgend was an Deiner Serverkonfiguration geändert oder programme deinstalliert?
     
  8. osterhase

    osterhase New Member

    Liegt am monitor_core_module.inc.php im mods-core. Hab das jetzt erstmal raus genommen, damit die Änderungen generell durchlaufen.
     
  9. osterhase

    osterhase New Member

    Gut... bin noch einen Schritt weiter gekommen. Es liegt am _monitorDiskUsage()-Step. Den habe ich auskommentiert und jetzt läuft's wieder durch.

    Da scheint was mit den quota-Einstellungen nicht in Ordnung zu sein. Oder?
     
  10. Till

    Till Administrator

    Der Monitor ist der teil von ISPConfig, der den Systemstatus erfasst und auswertet.

    Ja, der Monitor wird aufgerufen, wie ich oben geschrieben habe.

    Ja, gut ,möglich. Was passiertd enn wenn Du die repquota Befehle von Hand ausführst.
     
  11. osterhase

    osterhase New Member

    Welche Befehle werden denn in dem Modul (monitor_core_module.inc.php - oder wo finde ich die?) gegeben - bin da nich so ganz durchgestiegen. Requoata -v -s -a gibt jedenfalls eine sinnhafte Ausgabe zurück.
     
  12. Till

    Till Administrator

    Wenne sum das hdquota und nicht email quota geht, dann sind es diese hier:

    repquota -au

    repquota -ag
     
  13. osterhase

    osterhase New Member

    Läuft beides mit ner sinnhaften Ausgabe durch. Heute Nacht ist auch cron_daily stehen geblieben. Wenn ich es händisch über die Shell durchlaufen lasse, gibt's allerdings keine Probleme.

    Was wird denn noch in dem _monitorDiskUsage()-Step gemacht oder wo kann ich das nachlesen?
     
    Zuletzt bearbeitet: 13. Juli 2012
  14. Till

    Till Administrator

    Schau mal ins monitor tools script in /usr/local/ispconfig/server/lib/classes/, dort stehen alle aufgerufenen Funktionen des Monitors drin. Im cron_daily wird aber nichts von dem aufgerufen, drt laufen nur Statistik und backup jobs.
     
  15. osterhase

    osterhase New Member

    Vielen Dank für die Hilfe - ich habe rausbekommen, woran es lag. Nachdem der Fehler nur noch im daily_script war, war das ja glücklicherweise auch nicht mehr alles superdrängend.

    Der Backup-Space (FTP) wurde als Loop-Device eingebunden. Als (aus welchen Gründen auch immer) das Loop-Device nicht mehr ungemountet werden konnte, ist df -h hängen geblieben und so konnte die Festplattenbelegung nicht mehr ausgelesen werden und das Skript ist stehen geblieben.
     

Diese Seite empfehlen