Seit Update auf 3.0.5.1 hält ISPConfig alle geänderten vhost-Konfigurationen defekt

#1
Guten Abend an alle!

Mein ISPConfig findet nach dem Update auf 3.0.5.1 alle geänderten vhost-Konfigurationen von Apache defekt. :confused: Selbst wenn z.B. nichts außer einem einzigen Kommentar drinnen steht. :eek: Wenn man die .err von Hand in "ohne .err" umbenennt und Apache2 durchstartet laufen sie aber problemlos. :eek: Selbst das Debug gab mir leider keine näheren Informationen über den Fehler. Hat jemand anderes ein ähnliches Problem oder ne Idee wo ich suchen könnte?

Hier die Eckdaten meines Systems und das Output der server.sh

Linux-Distribution Ubuntu 10.04 amd64
ISPConfig 3.0.5.1

Output der server.sh mit eingeschaltetem Debug:
PHP:
root@www ~ # /usr/local/ispconfig/server/server.sh
07.03.2013-21:26 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
07.03.2013-21:26 - DEBUG - Found 1 changes, starting update process.
07.03.2013-21:26 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_update'.
07.03.2013-21:26 - DEBUG - Calling function 'update' from plugin 'apache2_plugin' raised by event 'web_domain_update'.
07.03.2013-21:26 - DEBUG - exec: usermod --groups sshusers web45 2>/dev/null
07.03.2013-21:26 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-scripts/web45/.php-fcgi-starter
07.03.2013-21:26 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/bilder.brandguides.net.vhost
07.03.2013-21:26 - DEBUG - Apache status is: 1
07.03.2013-21:26 - DEBUG - Calling function 'restartHttpd' from module 'web_module'.
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.74:80 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.74:443 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.73:443 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.77:80 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.76:443 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.74:80 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.74:443 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.73:443 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.77:80 has no VirtualHosts
[Thu Mar 07 21:26:45 2013] [warn] NameVirtualHost 78.46.123.76:443 has no VirtualHosts
07.03.2013-21:26 - DEBUG - Apache online status after restart is: 
07.03.2013-21:26 - WARNING - Apache did not restart after the configuration change for website bilder.brandguides.net Reverting the configuration. Saved non-working config as /etc/apache2/sites-available/bilder.brandguides.net.vhost.err
07.03.2013-21:26 - DEBUG - Calling function 'restartHttpd' from module 'web_module'.
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.74:80 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.74:443 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.73:443 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.77:80 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.76:443 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.74:80 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.74:443 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.73:443 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.77:80 has no VirtualHosts
[Thu Mar 07 21:26:52 2013] [warn] NameVirtualHost 78.46.123.76:443 has no VirtualHosts
07.03.2013-21:26 - DEBUG - Processed datalog_id 862
07.03.2013-21:26 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
finished.
Die warn Meldungen waren übrigens schon länger da und haben bis jetzt nicht gestört.

Lg
Kristian
 

Till

Administrator
#2
Die Warn Meldungen sind ok so.

Zu den .err Dateien, entweder ein Apacahe lauscht nicht auf localhost oder er braucht mehr als 7 Sekunden für einen restart, so dass ISPConfig die Konfiguration für defekt hält.
 
#3
Danke für Deine Antwort Till! :D

Zu den .err Dateien, entweder ein Apacahe lauscht nicht auf localhost
Das kann ich ausschließen

oder er braucht mehr als 7 Sekunden für einen restart, so dass ISPConfig die Konfiguration für defekt hält.
Das wundert mich, weil es mir gefühlt nicht so lange vorkommt und die .err Dateien ja erst nach dem Update von ISPConfig auftauchen. Aber durch diverse umfangreiche Webseiten mit fast-cgi usw. könnte es möglich sein. Kann man den Zeitraum hochsetzen?

Lg
Kristian
 
#4
Habe inzwischen entdeckt, dass es auch bei einem
Code:
/etc/init.d/apache2 restart
zu einem Fehler kommt. Das init-script gibt einem dann die folgende Rückmeldung

Code:
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Wenn man anstelle von restart mit start oder stop arbeit gibt es keine Fehler. Es scheint also, als wenn Ubuntu zu schnell den Server wieder starten will und er zu dem Zeitpunkt noch nicht beendet ist. Scheint also eher ein Ubuntu-Problem zu sein.:(

Ich werde weiter suchen ...

Lg
Kristian
 
#5
Leider funktioniert ein
Code:
/etc/init.d/apache2 restart
auch nicht, wenn ich ein sleep 2 einbaue. Ein
Code:
apache2ctl restart
scheint wiederum immer zu funktionieren.:confused: Und warum tritt das Problem erst nach dem Update von ISPConfig auf? :(

Ich komme aktuell nicht auf den Zusammenhang und bin mit meinem Latein erst mal am Ende. Vielleicht fällt mir ja noch was ein, wenn ich noch mal eine Nacht darüber geschlafen habe. Hat jemand anderes noch ne Idee, wo ich suchen könnte?

Lg
Kristian
 
#7
Danke für die Antwort Till. Ich bin mir aber sicher, dass das sleep richtig ist. Auch wenn ich ein sleept von 5 oder 10 im Bereich für stop verwende, wird die Fehlermeldung nach nicht mal einer Sekunde ausgeworfen. Offensichtlich scheint die Restart-Routine zu denken, dass der Apache nicht läuft. Deshalb wird sofort ein start versucht. Anders kann ich mir die schnelle Fehlermeldung nicht erklären.

Lg
Kristian
 
#8
Aha ... jetzt hab ich ne'n Workaround. Wenn man am Ende der Funktion apache_wait_stop() im Init-Script ein sleep 2 einbaut geht es. Wenn man es vor der if [ -n "${PID:-}" ]; then Schleife einbaut geht es nicht.

Code:
apache_wait_stop() {
        # running ?
        PIDTMP=$(pidof_apache) || true
        if kill -0 "${PIDTMP:-}" 2> /dev/null; then
            PID=$PIDTMP
        fi

        apache_stop

        # wait until really stopped
        if [ -n "${PID:-}" ]; then
                i=0
                while kill -0 "${PID:-}" 2> /dev/null;  do
                        if [ $i = '60' ]; then
                                break;
                        else
                                if [ $i = '0' ]; then
                                        echo -n " ... waiting "
                                else
                                        echo -n "."
                                fi
                                i=$(($i+1))
                                sleep 1
                      fi
                 done
        fi
sleep 2
}
Der while scheint also nicht lange genug auf den Kill-Befehl zu warten. Warum auch immer.:) Mich wundert nur das bis jetzt kein anderer so ein Problem hat. :confused: Vielleicht habe ich es aber auch nur nicht gefunden. Es macht kein Spaß nach einer solchen Fehlermeldung zu googeln. Da findet man nur lauter Leute, die schon irgend welche anderen Anwendungen auf Port 80 laufen haben :p

Lg
Kristian
 

Till

Administrator
#9
Danke für das posten der Lösung! An sich ist es ja ein Bug in Ubuntu, habe aber keinen Launchpad account um es bei denen zu posten. Denn solange sie init scripte anbieten sollten sie auch funktionieren :)
 
#10
Ist doch klar das man die Lösung hier postet! Habe in diesem tollen Forum auch schon oft den rettenden Hinweis gefunden. Sogar schon ab und zu für Probleme, die nichts mit ISPConfig zu tun haben.

Ich habe zwar einen Lunchpad Account, finde das Problem aber aktuell noch zu unklar um einen Fehler zu melden. Bei den ganzen Webseiten mit fast-cgi auf meinem Server kann man ja nicht mehr von einer Standard-Installation reden. Außerdem war das Echo hier bis jetzt ja gering. Könnte also wirklich sein, dass nur ich das Problem habe und 10.04 ist ja auch nicht mehr taufrisch bzw. bei 12.04 gibt eine neuere Apache-Version und ein anders init-Skript.

Lg
Kristian
 

Werbung

Top