Hi,
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
Viele Grüße Clemens
Moin,
Am Samstag, den 20.02.2016, 01:14 +0100 schrieb Clemens John via Admin:
Hi,
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.
vg
Hi,
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.
vg Tarek
Das habe ich mir grade auch gedacht. Habe auch schoin Timeouts entsprechend geändert und häng an dem Problem seit 7 Uhr dran :/
Am 20.02.2016 um 09:53 schrieb Jan-Tarek Butt via Admin:
Interessant daran ist das, das gitlab auf einen ganz anderen Server läuft. Die einzige Gemeinsamkeit die sie haben ist der selbe hoster netcup.
Hi,
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
vg Tarek
Hoi,
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
Mein er bezüglich der Webserver-Thematik?
vg
On 02/20/16 10:29, Bjoern Franke via Admin wrote:
Hoi,
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
Mein er bezüglich der Webserver-Thematik?
Den timeout foor bei mail und web vermutlich. Wobei es da ja auch nur die php anwändungen betrifft.
Er meldet sich ab 12/13 uhr noch mal denke ich.
vg Tarek
Am Samstag, 20. Februar 2016, 10:02:07 CET schrieb Jan-Tarek Butt via Admin:
(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
Hi,
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.
Hey,
wir waren alle auf dem Holzweg:
Der MySQL von srv07.ffnw.de nimmt per v6 keine Verbindungen mehr an, wird die v4 dort eingetragen läuft es alles wieder :)
Besten Dank Felix! Ich fixe grade alle Seiten.
Stefan
Am 20.02.2016 um 12:12 schrieb Clemens John via Admin:
Am Samstag, 20. Februar 2016, 10:02:07 CET schrieb Jan-Tarek Butt via Admin:
(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
Hi,
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.
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Am Samstag, 20. Februar 2016, 12:37:17 CET schrieben Sie:
Der MySQL von srv07.ffnw.de nimmt per v6 keine Verbindungen mehr an, wird die v4 dort eingetragen läuft es alles wieder :)
Stop! Ich kann auch einfach v6 dort wieder aktivieren. Fragt mich nicht, warum das nicht mehr läuft, ich hatte das ja mal extra eingeschaltet.
LG Clemens
Am Samstag, 20. Februar 2016, 12:39:30 CET schrieb Stefan:
Das wäre natürlich noch einfacher ;) Sagst du Bescheid wenn es aktiv ist?
Hi,
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!
Viele Grüße Clemens
Hoi,
Am Samstag, den 20.02.2016, 12:37 +0100 schrieb Stefan via Admin:
Hey,
wir waren alle auf dem Holzweg:
Der MySQL von srv07.ffnw.de nimmt per v6 keine Verbindungen mehr an, wird die v4 dort eingetragen läuft es alles wieder :)
Besten Dank Felix! Ich fixe grade alle Seiten.
Wer hat denn Postfix auf srv01 auf ipv4-only gestellt?
vg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 20.02.2016 um 09:53 schrieb Jan-Tarek Butt via Admin:
Interessant daran ist das, das gitlab auf einen ganz anderen Server läuft. Die einzige Gemeinsamkeit die sie haben ist der selbe hoster netcup.
bitte ticket beim hoster erstellen.
- -- Gruß pic
Xmpp: picard@ffnw.de & picard@fr32k.de @ME https://wiki.nordwest.freifunk.net/picard
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
picard -
Stefan