Asterisk auf vServer "spinnt"

Und wieder geht nichts mehr.

Jeden Sonntag Morgen ist mein Starhosting-vServer tot. Auch der Apache geht nicht, auch Reboot hilft nichts. Man kann nur einige Stunden warten. Naja, mich sind die los, ich warte nur noch auf die Freischaltung bei Topnetworks. Hoffentlich ist es dort besser.

Finger weg von Starhosting!
 
Ach Mensch,

das ist ja traurig zu hören. Was mich noch interessieren würde ist, was Du mit "tot" meinst. Steht der vServer wirklich? Oder sind die Dienste von außen nur schlecht/nicht zu erreichen? Was geht denn, und was nicht?
 
Nach dem ich den Supprt nochmals angeschrieben und auf diesen Thread aufmerksam gemacht habe, ist jetzt bei mir Ruhe eingekehrt:
vsXXXX:~# asterisk -rx "show uptime"
System uptime: 6 days, 1 hour, 3 minutes, 5 seconds
 
Was mich noch interessieren würde ist, was Du mit "tot" meinst. Steht der vServer wirklich? Oder sind die Dienste von außen nur schlecht/nicht zu erreichen? Was geht denn, und was nicht?
Gar nichts geht. Kein SSH, kein Asterisk, kein Apache. Nur Pingen lässt er sich. In diesen Status verfällt er hin und wieder, und mit Regelmäßigkeit jeden Sonntag Vormittag.

Ein paar Stunden später ging er wieder.
 
So, es ist wieder Sonntag morgen, und mein vServer ist wieder mausetot. Das wird sich wohl in ein paar Stunden wieder einrenken. Das ist jeden Sonntag so.

Können bitte andere Starhosting-Kunden schauen, ob ihre vServer leben?
 
Vor zwei Tagen wurde irgendwann in der Nacht Asterisk wieder gestoppt. Konnte ihn dann am Morgen aber normal aktivieren.
vsXXXX:~# asterisk -rx "show uptime"
System uptime: 2 days, 1 hour, 8 minutes, 38 seconds
Könnte es sein, dass Dein vServer hardwaremässig mit jemandem geteilt wird, der dieses Problem verursacht???
 
Könnte es sein, dass Dein vServer hardwaremässig mit jemandem geteilt wird, der dieses Problem verursacht???
Das wäre auch mein Verdacht. Aber Starhosting ist nicht bereit, darauf einzugehen. Also muss ich weg, was bleibt mir denn anderes übrig?
 
Und einen Resourcenmangel des Hosts scheidet aus? VServer haben tlw. sehr regide Einschränkungen vor allem bei den Resourcen. Wenn alle dann alle. Bei manchen funktioniert noch nicht mal ein Webserver unter last vernünftig.
 
Starhosting behauptet, im Gegensatz zu so mancher Konkurrenz nur 70% der Kapazität zu nutzen, damit Puffer da ist. Ich habe mich ja schon zunächst sehr freundlich, dann Nachdücklicher an den Support gewandt.

Die lapidare Antwort ist, sie stellen die Infrastruktur zur Verfügung, der Rest ist meine Sache. Das sehe ich ja auch ein, für 3 Euro im Monat kann wirklich keiner verlangen, dass sie meine Konfiguration supporten. Nur bin ich zur Überzeugung gelangt, dass mein Problem jenseits meines vServers liegt (am Host, bei den "Nachbarn", im Netzwerk oder sonst wo). Und das ist schon deren Sache.

Wenn ich endgültig umgezogen bin, werde ich einmal ein ganz nacktes Debian Image installieren und schauen, ob es einen Sonntagmorgen überlebt. Wenn es das nicht tut, ist die Sache klar.
 
Macht mal

cat /proc/user_beancounters

Wenn in der Spalte failcnt irgendwas größer 0 ist gibts ein Problem.
 
Vor zwei Tagen wurde irgendwann in der Nacht Asterisk wieder gestoppt. Konnte ihn dann am Morgen aber normal aktivieren.Könnte es sein, dass Dein vServer hardwaremässig mit jemandem geteilt wird, der dieses Problem verursacht???

Also IMHO sieht das nach zwei Möglichkeiten aus:

. Starhosting macht Zwangsboot. Danach könnte man sie aber fragen. Die systemweiten Logfiles (u.a. Distributionen z.B. /var/log/messages) müssten dann weitere Informationen enthalten. Ausserdem müsste Starhosting zu solchen Punkten eindeutig Antwort geben.

. Der Asterisk stirbt wegen Ressourcenmangels von selbst weg (wie gesagt, die internen Walltime-abhängigen Module machen Asterisk gewiss empfindlicher als andere Software). Andere Dinge müssten dann aber weiterlaufen, so z.B. Webserver. Aber auch wenn Asterisk wegstirbt, sollte sich das nicht nur im CLI abfragen lassen, sondern aus Logfiles (z.B. Asterisk-eigene oder syslog) hervorgehen.

. Generell kann bei einer guten Virtualisierungstechnik nichts, was nicht walltimeabhängig ist, wegsterben. Wenn es Ressourcenverknappung gibt (sei es im Scheduling, oder bei der NIC), erscheint die VM gegenüber der Außenwelt gewissermaßen "eingefroren", entspräche also der Beobachtung, dass von Asterisk über SSH bis zum Apache u.U. nichts zu erreichen ist. Davon taucht dann auch in Logfiles nichts auf. Dieser Zustand müsste aber, selbst wenn hier Snapshotting o.ä. die Ursache ist, nach wenigen Sekunden bis schlimmstenfalls Minuten vorüber sein.

Aus eigener Erfahrung mit meinem vServer (bei einem anderen Provider) stammt die Beobachtung, dass nächtens der Provider über den XEN-Kernel ein zwangsweises sync() einblendet, wahrscheinclih werden in jenem Moment zwangsweise Snapshots von allen laufenden VMs gezogen. Das ist aber die einzige Beobachtung. Ungewollte Reboots oder Stopps von Diensten gab es derweil noch nicht.
 
So, jetzt mein Epilog vom Wochenende. Ich habe diesen Sonntag den Support nicht kontaktiert, sondern abgewartet was passiert. Offenbar ist der vServer zwischen 13:45 und 14:00 wieder erwacht: Laut seiner Uptime wurde mein Asterisk um 14 Uhr neu gestartet. (Ich habe einen Crontab-Eintrag, der Asterisk jede Viertelstunde startet). Das heißt, in seiner "Auszeit" war der vServer nicht nur nicht erreichbar, sondern er wurde neu gestartet.

Ich habe den Asterisk jetzt zu Topnetworks übersiedelt. Hoffentlich geht es mir dort besser. Bei Starhosting habe ich nun ein neues "nacktes" Debian 4.0 Image eingespielt. Ich werde jeden Tag nachsehen, ob der Server erreichbar ist, und bin schon neugierig, was am Sonntag sein wird.

Aber nun noch eine Frage zu meinem neuen Server: Topnetworks bietet auch ein Image mit bereits vorinstaliertem Asterisk an. Das ist aber ein 1.4.x. Ich arbeitete bisher mit 1.2.x. So viel ich gelesen habe, hat sich mit 1.4 so manches in den conf-Dateien geändert. Gibt es irgendwo eine gute Zusammenfassung, was davon betroffen ist?

Für jetzt habe ich mir ein leeres Debian genommen und einen Asterisk 1.2.x selbst compliliert, aber wenn die schon ein fertiges Asterisk-Image anbieten, dann bin ich dazu geneigt es zu verwenden, da ich davon ausgehe, dass das erstens getestet ist und zweitens auch von anderen Usern verwendet wird.
 
Alles halb so wild. Ich habe auch von 1.2 auf 1.4 gewechselt. Ist aber schon etwas länger her. Es waren aber nur Kleinigkeiten die verändert werden musten. Das waren meist nur Variablen wie Callerid die etwas anders geschrieben werden mussten. Das kannste aber ganz gut gucken auf der Webseite http://www.das-asterisk-buch.de da steht das schön in Übersicht was sich zu den einzelnen Versionen verändert hat. Also einfach mal reinladen die Extension.conf und relaod. Dann kannste die Fehler abarbeiten und und alle Schleifen die du dir gebaut hast abtelefonieren und dann sollte es schon laufen ;-)
 
Gestern habe ich eine Änderung in der sip.conf gemacht und wollte reloaden. Der Befehl wurde jedoch nicht akzeptiert; es passiert gar nichts bzw. diese Eingabe wird einfach ignoriert. Asterisk scheint aber zu funktionieren. Andere Befehle werden ausgeführt; "sip show registry" zeigt auch, dass die Provider registriert sind, dies jedoch ohne die vorgenommene Änderung bzw. ohne reload. Ein Reboot änderte nichts an dieser Situation. Werde sehen, ob sich daran nächstens etwas ändert. Gewinne langsam auch den Eindruck, dass die vServer von StarHosting für Asterisk ungeeignet zu sein scheinen.
 
Mein "leerer" vServer hingegen geht jetzt, obwohl es Sonntag Morgen ist. Vielleicht verträgt sich wirklich was nicht mit Asterisk.

Mein Topnetworks Asterisk läuft jetzt laut "show uptime" 4 Tage und 15 Stunden. Das ist seit ich ihn eingerichtet habe. Mal sehen in den nächsten Wochen.
 
Mein "leerer" vServer hingegen geht jetzt, obwohl es Sonntag Morgen ist. Vielleicht verträgt sich wirklich was nicht mit Asterisk.
Was bedeutet "leer"; mit Asterisk aber inaktiv oder ohne Asterisk? Falls mit Asterisk: geht "reload"?

Nachtrag:
Habe übersehen, dass weiter oben die Antwort schon gegeben wurde: "Bei Starhosting habe ich nun ein neues "nacktes" Debian 4.0 Image eingespielt."
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.