es gibt ein bisher unbekanntes Problem auf srv01. Wir haben das Problem soweit
eingegrenzen können, das wir wissen, dass nur bestimmte Anwendungen betroffen
sind.
Dazu gehörte bis heute Nachmittag der Mailserver, den Bjo dann gefixed hat. @Bjo evtl. kannst du hier nochmal zwei Sätze dazu schreiben.
Außerdem betroffen sind alle PHP-Anwendungen sowie das Gitlab.
Alles andere (Pads, Wiki, Munin, SSH etc.) läuft ohne Probleme. Unter
besonderer Last steht der Server ebenfalls nicht, sprich alle Monitoring-Werte
sind normal. Der Server ist per SSH normal erreich- und bedienbar.
Die einzige Veränderung im Monitoring ist die signifikante Erhöhung der Munin
execution time, wobei Munin relativ sicher nicht das Problem ist sondern hier
Zeigt sich nur die Auswirkung: https://status.nordwest.freifunk.net/munin/
ffnw.de/srv01.ffnw.de/index.html
es gibt ein bisher unbekanntes Problem auf srv01. Wir haben das
Problem soweit
eingegrenzen können, das wir wissen, dass nur bestimmte Anwendungen
betroffen
sind.
Dazu gehörte bis heute Nachmittag der Mailserver, den Bjo dann
gefixed hat. @Bjo evtl. kannst du hier nochmal zwei Sätze dazu schreiben.
IMHO resultierte das Mailproblem woanders her. qmgr und trivial-rewrite
im Debug-Mode zeigten folgendes:
Feb 19 17:48:45 srv01 postfix/trivial-rewrite[2488]:
dict_mysql_get_active: attempting to connect to host srv07.ffnw.de
Feb 19 17:49:45 srv01 postfix/qmgr[2458]: warning: problem talking to
service rewrite: Connection timed out
In den Configs für das Lookup von Domains, Usern etc. war als MySQL-
Host srv07.ffnw.de eingetragen, ich habe dies dann zu der IPv4-Adresse
des Hosts geändert.
es gibt ein bisher unbekanntes Problem auf srv01. Wir haben das Problem soweit
eingegrenzen können, das wir wissen, dass nur bestimmte Anwendungen betroffen
sind.
Dazu gehörte bis heute Nachmittag der Mailserver, den Bjo dann gefixed hat. @Bjo evtl. kannst du hier nochmal zwei Sätze dazu schreiben.
Außerdem betroffen sind alle PHP-Anwendungen sowie das Gitlab.
Alles andere (Pads, Wiki, Munin, SSH etc.) läuft ohne Probleme. Unter
besonderer Last steht der Server ebenfalls nicht, sprich alle Monitoring-Werte
sind normal. Der Server ist per SSH normal erreich- und bedienbar.
Die einzige Veränderung im Monitoring ist die signifikante Erhöhung der Munin
execution time, wobei Munin relativ sicher nicht das Problem ist sondern hier
Zeigt sich nur die Auswirkung: https://status.nordwest.freifunk.net/munin/
ffnw.de/srv01.ffnw.de/index.html
Interessant daran ist das, das gitlab auf einen ganz anderen Server
läuft. Die einzige Gemeinsamkeit die sie haben ist der selbe hoster netcup.
es gibt ein bisher unbekanntes Problem auf srv01. Wir haben das Problem soweit
eingegrenzen können, das wir wissen, dass nur bestimmte Anwendungen betroffen
sind.
Dazu gehörte bis heute Nachmittag der Mailserver, den Bjo dann gefixed hat. @Bjo evtl. kannst du hier nochmal zwei Sätze dazu schreiben.
Außerdem betroffen sind alle PHP-Anwendungen sowie das Gitlab.
Alles andere (Pads, Wiki, Munin, SSH etc.) läuft ohne Probleme. Unter
besonderer Last steht der Server ebenfalls nicht, sprich alle Monitoring-Werte
sind normal. Der Server ist per SSH normal erreich- und bedienbar.
Die einzige Veränderung im Monitoring ist die signifikante Erhöhung der Munin
execution time, wobei Munin relativ sicher nicht das Problem ist sondern hier
Zeigt sich nur die Auswirkung: https://status.nordwest.freifunk.net/munin/
ffnw.de/srv01.ffnw.de/index.html
Interessant daran ist das, das gitlab auf einen ganz anderen Server
läuft. Die einzige Gemeinsamkeit die sie haben ist der selbe hoster netcup.
Hier noch ein hinweiß von fkr
(09:57:55) fkr: das was ihr da debugged, klingt sehr stark nach v6 over
v4 preference, einem service der nicht auf v6 lauscht, wegen der
preference aber zunaechst auf v6 angesprochen wird, bis in einen timeout
gelaufen wird
(09:58:29) fkr: bzw. dort auf v6 gefiltert wird, deswegen kein
connection refused kommt, sondern in einen timeout gelaufen werden muss
(09:57:55) fkr: das was ihr da debugged, klingt sehr stark nach v6
over
v4 preference, einem service der nicht auf v6 lauscht, wegen der
preference aber zunaechst auf v6 angesprochen wird, bis in einen
timeout
gelaufen wird
(09:58:29) fkr: bzw. dort auf v6 gefiltert wird, deswegen kein
connection refused kommt, sondern in einen timeout gelaufen werden
muss
ich habe damit leider keine Erfahrung, aber evtl. hilft ein Debug-Log vom
Nginx um den Sachverhalt besser zu beurteilen. Ich habe dazu error_log vom
Ticket-vHost (https://support.nordwest.freifunk.net/) auf debug gesetzt (dort
ist weniger Traffic sodass ich meine eigene Anfrage im Log filtern kann):
Wenn ich das richtig beurteile, dann bekommt Nginx einen Timeout von php-fpm.
Siehe Zeile 214 und gibt den als 504 Gateway Time-out an mich als Benutzer
weiter.
Die Kernfrage ist: warum liefert php5-fpm einen timeout anstatt die Anwendung
zurück zu liefern. Auf dem blog vHost ist das verhalten ähnlich, auch wenn
nginx nicht explizit einen 504 zurück liefert. Aber ein Timeout bekommt nginx
dort ebenfalls.
Viele Grüße
Clemens
P.S. fkr ist jetzt für eine Stunde an srv01, ich bin erstmal raus und
Frühstücken.
das Problem ist behoben. Hier nochmal kurze Analyse:
* Bestimmte Services (Mail, PHP, Gitab) fallen ohne ersichtlichen Grund aus,
Monitoring zeigt keine Auffälligkeiten (gestern)
* Erkenntnis, dass es bei Mail ein Problem mit der Verbindung zur Datenbank
auf srv07 gibt (gestern) "In den Configs für das Lookup von Domains, Usern etc.
war als MySQL- Host srv07.ffnw.de eingetragen, ich habe dies dann zu der IPv4
Adresse des Hosts geändert." --> hier hätten wir weiter bohren müssen,
manchmal sieht man aber den Wald vor lauter Bäumen nicht
* Erkenntnis, dass bei den PHP-Anwendungen die Datenbank nicht erreichbar ist
(heute)
* Erkenntnis, dass die Datenbank nur per IPv6 nicht erreichbar ist
* Erkenntnis, dass die Datenbank vollständig korrekt konfiguriert ist und
Verbindungen per IPv6 erlauben sollte
* Erkenntnis, dass srv07 vollständig nicht per IPv6 erreichbar ist
* Erkenntnis, dass srv07 auch nicht per IPv6 nach draußen kommunizieren kann
(Network not reachable)
* Google, erste Hinweise, dass dies mit einem Update von Wheezy auf Jessie auf
srv07 zusammenhängen könnte: https://debianforum.de/forum/viewtopic.php?
f=30&t=155612
* Frage: warum zeigen sich die Auswirkungen erst jetzt? Das Update ist Wochen
her...
* Erkenntnis, dass tatsächlich der IPv6 Gateway fehlt
* Check der IPv6 config, was empfiehlt Netcup dazu http://www.netcup-wiki.de/
wiki/Zus%C3%A4tzliche_IP_Adresse_konfigurieren#IPv6
* IPv6 Gateway konfiguriert, Netzwerk neu gestartet, Problem gelöst
Puhh! Das war echt ne harter Nuss. Danke an alle Beteiligten!
