.ispconfig_lock bleibt stehen

[osterhase]

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:

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

 

[Till]

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.

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 (?).

Ja.

 

[osterhase]

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?

 

[Till]

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

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?

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

 

[osterhase]

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:

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.

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.

 

[osterhase]

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

Jemand noch nen heißen Tipp?

 

[Till]

Dachte irgendwie ich müsste das mit dem Logging hart in der config umstellen...

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

Dann bleibt's allerdings eine Minute später wieder stehen.

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?

 

[osterhase]

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

 

[osterhase]

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?

 

[Till]

Was meinst Du mit Monitor? Wird nicht immer die server.php ausgeführt ob nun Monitor (Weboberfläche?) oder Konsole?

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

Abgesehen davon bleibt der Update-Prozess stets bei 5 bzw. 10 Minuten stehen (auch von der Shell aus angestoßen) passiert da was besonderes im Skript?

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.

 

[osterhase]

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.

 

[Till]

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

repquota -au

repquota -ag

 

[osterhase]

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?

 

[Till]

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.

 

[osterhase]

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.