Beiträge von teneco

Guten Morgen monst12,

also bei mir läuft die Sache seit dem 29.6. 18:56 stabil ohne weitere Aussetzer. Du kannst ja einfach prüfen ob Du das gleiche Problem hast wie ich: z.B. von dem heimischen PC aus ein MTR (oder winMTR bei Windows) zu Deinem Root-Server. Bei mir reichte auch ein MTR von einem Root-Server zum anderen - während so ein Trace lief gab es bei mir nie Aussetzer.

Vielleicht habe ich aber auch eine besonders "ruhige IP-Adresse" erwischt: im syslog gibt es tatsächlich Pausen in denen 2 bis 3 Minuten nichts protokolliert wird; bei meinen anderen Root-Servern liefert da alle paar Sekunden die FW irgendwelche Einträge.

A pro pos Ubuntu syslog: zum Thema PowerManagement findet sich da ein Eintrag: "acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM"

Also das mit den Neu- und Bestandskunden verstehe ich noch nicht: nehmen wir die Aktion ".de-Domain 15 years". Da müsste ich doch als Bestandskunde mir eine weitere de-domain für 015€/Monat dazu buchen können. Wähle ich das Produkt aus werde ich auch prompt gefragt ob ich bereits Kunde bin und die domain über das CCP dazu buchen möchte - das CCP kennt dann aber den Aktionspreis nicht. Gilt das Angebot also nur für Neukunden? Dann wäre aber die Beschreibung "Mit den zusätzlichen Domains können Sie Ihr Webhostingpaket, Ihren vServer oder dedizierten Server um weitere Domains erweitern." unglücklich gewählt.

Von mir natürlich auch einen herzlichen Glückwunsch und weiter so!

Also ich fasse noch einmal zusammen: wenn man meinen "RS500SAS G7" bzw. den Host beschäftigt, z.b. mit einem dauerhaft laufenden MTR funktioniert alles tadellos. Bei Unterbeschäftigung scheint etwas beim Host stehen zu bleiben. Meine Maschine läuft in der Zeit weiter, triggert in der Zeit z.B. ein Cron-Job die Munin-Server SW und versucht diese dann Daten von einem anderen "RS500SAS G7" auf einem anderen Host zu pollen kommt keine Verbindung zustande. Auch externe SMTP- oder HTTP-Anfragen werden zu dieser Zeit nicht beantwortet (erreichen gar nicht den vServer). Diese Blackout-Phasen dauern etwa eine bis drei Minuten - dann kommen Anfragen wieder durch.

Der zweite "RS500SAS G7", auf einem anderen Host hat diese Probleme nicht.

Meine Idee wäre es noch einen MTR zu einer anderen virtuellen Maschine auf dem selben Host laufen zu lassen. Wenn dann auch die Probleme in meiner virtuellen Maschine weg wären - dann läge es am Host, oder?

Nach mehreren Tagen Ruhe gab es jetzt wieder Probleme. Sowohl das externe Monitoring schlug an als auch der interne Verkehr zwischen zwei vServern auf unterschiedlichen Hosts stockte. Zuerst zum externen Monitoring:

22.06.2017 01:55:02 Socket timeout after 11 seconds von 212.72.183.125 (Hamburg)

22.06.2017 01:56:02 Socket timeout after 11 seconds von 193.164.132.46 (München)

22.06.2017 01:57:02 Socket timeout after 11 seconds von 5.83.128.154 (Frankfurt)

Um 1:58 kommen wieder Anfragen durch und werden im syslog protokolliert; zwischen 1:55 und 1:58 gibt es im syslog keine Einträge.

Ähnliches spielt sich um 22.06.2017 02:10:02 ab. Um 2:10:53 gibt es im syslog einen Eintrag der FW, danach ist für 2min Stille.

Dann um 22.06.2017 02:55:02 für drei Minuten. In der Zeit wurde eine Mail von einem anderen vServer bei NC entgegengenommen, die FW wies Anfragen an die Ports 22 und 23 zurück. Rechner und Netzwerk müssen da eigentlich oben gewesen sein.

22.06.2017 05:04:02 - nichts besonderes im logfile; cron-jobs werden abgearbeitet

22.06.2017 08:25:02 - nichts besonderes im logfile; cron-jobs werden abgearbeitet

Jetzt die missglückten Munin Abfragen zu dem anderen vserver auf einem anderen host:

00:25

00:35

01:05

01:55 da klemmte auch das ext Mon

02:10

02:35

02:40

02:50

02:55

04:00

04:10

05:05

....

08:25 letzter Fehler für heute

Wie schon weiter oben beschrieben treten die Fehler während eins laufenden MTR (zwischen den vServern oder einem PC und dem Server) nicht auf. Bei wenig Auslastung scheint irgendein Prozess im Swap zu landen - aber welcher und wo? Könnte nicht auch der Host an dem Dilemma beteiligt sein?

Es widerstrebt mir auch den Rechner permanent zu beschäftigen, nur damit das Problem nicht auftritt.

Hallo Christian,

danke für Deinen Schuss ins Blaue, ich bin wirklich für jede Anregung dankbar. Postfix beantwortet ja diese smtp Anfragen. Gegen Deine These spricht, dass zu den Zeiten in denen die Antwortzeiten so hoch gehen auch keine anderen Prozesse so wirklich funktionieren - so setzt ja auch das munin polling in diesen Zeiten aus (von einem anderen "root Server")

Ich werte das Verhalten von postfix und dovecot aus - aber es sind keine Merkwürdigkeiten zu beobachten. Allerdings läuft der Rechner jetzt auch seit zwei Tagen stabil, die SMTP Response Time liegt zwischen 0,3 und 2s bei einem Abfrageintervall von 30 min, es gibt derzeit auch keine Lücken in den Munin reports.

Stefan

In der letzten Nacht gab es keinerlei erkennbare Probleme. Nach meiner These müsste noch ein weiteres Monitoring dazu gekommen sein weil sich jetzt die SMTP Response Time bei etwa 1s eingependelt hat - sicherlich beeinflusst auch der echte Mail-Verkehr die ganze Sache - deswegen traten die Probleme auch eher nachts auf.

Ich würde auch mit meinem betroffenen RS 500 SAS G7 SE 12M auf ein RS 1000 G7 SE (SAS) migrieren; wenn das so einfach möglich wäre.

Also je kürzer das externe Monitoring Intervall desto kürzer ist die SMTP Response Time!?

Solange ich den Server jede Minute Abfrage liegt die Zeit unter 0,4s. Ab Mittags habe ich das Intervall auf 30 min gesetzt und seitdem klettert die Response Time auf Werte über 7s! Ab 10s treten die Probleme auf. Woran könnte das liegen?

Gestern Nacht gab es noch 4 Probleme beim Munin polling: um 1:45, 5:25, 7:30 und 8:50.

In dieser Nacht gab es keine Unterbrechung; das einzige, das ich geändert habe, ist die Frequenz des externen Monitorings von alle 5 Minuten auf minütlich. Das war ja auch schon so, als ich vom heimischen PC ein MTR zum Server laufen liess - auch während dieser Zeit traten keine Probleme auf. Ich werde heute Abend das externe Monitoring unterbrechen - mal sehen ob es wieder Probleme gibt. Eine bestehende SSH-Verbindung schützt nicht vor den Problemen - die wird dann gekappt.

2017/06/12 00:40:19, 02:35:05, 03:35:04

Für das externe Monitoring sollten die Server aber auch nicht irgendwo in Übersee stehen - ich möchte ja die Verfügbarkeit des eigenen Servers testen und nicht die Stabilität irgendwelcher Seekabel.

Zurück zum Thema: heute um 8:25, 10:00, 12:05, 14:00, konnte der eine vServer (v22016114011140388) wieder den anderen (v22016124011141793) nicht erreichen, um seine Munin Daten zu pollen. Wenn ich von meinem PC aus zu beiden Servern eine SSH-Verbindung offen habe friert die zu v22016114011140388 dann immer ein.

Heute Nacht gab es um 3:30 Probleme; es gab wieder ein Problem bei der Munin Abfrage und eine eingehende email wurde zum Alternativ-Server, der mit MX 50 in der DNS Zone eingetragen ist gerouted. Vielleicht treten die Probleme häufiger auf - aber mein Abfrageintervall sind halt 5 Minuten.

In dieser Nacht gab es wieder zweimal Probleme: gegen 23:08 und 3:38.

In den letzten 24 h gab es keine Probleme - weder gibt es intern Streifen in Munin oder meckerte das externe Monitoring.

2017/06/08 05:45:04 [FATAL] Socket read from web.domain.de failed. Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.

2017/06/08 05:45:04 [ERROR] Munin::Master::UpdateWorker<domain.de;web.domain.de> died with '[FATAL] Socket read from web.domain.de failed. Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.

Betroffen ist bei mir die IP 37.120.173.xxx, NICHT betroffen ist 37.120.169.xxx

Heute Nacht (8.6). traten die Probleme zweimal auf: gegen 1:14 und 5:44 (+-3min). Evtl tritt das Problem auch öfter auf - wird nur nicht erkannt. Es sieht so aus als würde manchmal irgendeine Komponente zu langsam antworten.

auch via IPv4.

Man kann die Netzwerkprobleme auch in den Munin Reports sehen: immer wenn der Server seinen node nicht abfragen kann entsteht ein Streifen im Bild:

snip2.jpg

snip3.jpg

Gestern Abend gegen 22:30 ist es bei mir das letzte Mal aufgetreten; danach habe ich über Nacht einen MTR von dem anderen vServer zum Problemkandidaten laufen lassen und währenddessen trat kein weiteres Problem auf. Ohne den laufenden MTR wäre es wieder 4 bis 6 mal zu Verbindungsabbrüchen gekommen. Nachts treten sie häufiger auf als tagsüber.

snip.jpg

Hm, das eigentliche Problem ist noch immer nicht gelöst: alle paar Stunden ist der Rechner für ein paar Minuten isoliert; er ist ein Munin-Server; er versucht alle 5 Minuten Daten von seinem node abzurufen - auch ihn erreicht er nicht während so eines Blackouts. Der Node ist ein anderer vserver auf einem anderen Host und nur gw01.netcup.net ist dazwischen. Ansonsten ist nicht auffälliges zu entdecken. Vielleicht könnte man sich das doch mal jemand vom Support aus Sicht von gw01.netcup.net angucken? Der Letzte Ausfall war heute gegen 22:40; der davor gegen 10:04.

Hat noch jemand einen Tip was ich weiter untersuchen könnte?

All lights are green:

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor prese
  Drop-In: /run/systemd/generator/networking.service.d
           └─50-insserv.conf-$network.conf
   Active: active (exited) since So 2017-06-04 11:03:37 CEST; 11min ago
     Docs: man:interfaces(5)
  Process: 1127 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=
  Process: 1113 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [
 Main PID: 1127 (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 408.0K
      CPU: 59ms
   CGroup: /system.slice/networking.service

Jun 04 11:03:35 mail systemd[1]: Starting Raise network interfaces...
Jun 04 11:03:36 mail ifup[1127]: /sbin/ifup: waiting for lock on /run/network/if
Jun 04 11:03:37 mail systemd[1]: Started Raise network interfaces.

Was habe ich gemacht:

sudo ifup --ignore-errors ens3
Neustart

Dabei habe ich festgestellt, dass es da im Ordner /etc/network/if-up.d eine Datei ubuntu-fan gibt; auch dieses script antwortete mit einem Fehler; ich habe diese Dateien aus den Ordnern if-down.d, if-up.d entfernt.