RPS1 bleibt immer wieder stehen
Zitat von
yxc
Besteht das Problem immer noch? ( RPS +Lenny )
MfG
Ja, leider besteht das Problem immer noch (
http://forum.ovh.de/showthread.php?t=6625)
und niemand scheint etwas dagegen zu unternehmen.
Scheinbar ereilt es früher oder später jeden RPS I mit Lenny.
yxc wrote:
> Besteht das Problem immer noch? ( RPS +Lenny )
Nein, natürlich nicht. das Problem betraf wie geschrieben NUR die während der
BETA-Phase installierten RPS mit Lenny.
--
Felix
OVH Team
Zitat von
yxc
Besteht das Problem immer noch? ( RPS +Lenny )
MfG
Aktuell laufen meine (neuen) Lenny-Installationen seit mehreren Tagen stressfrei und stabil. War wohl wirklich nur ein temporäres Problem.
Zitat von
kro
Besteht das Problem immer noch? ( RPS +Lenny )
MfG
Meiner ist gestern gegen 11 Uhr (mittags) wieder stehen geblieben.
Weder im syslog noch in den aufgezeichneten sar-daten findet sich irgendein Hinweis auf einen Fehler, Hänger oder sonst was.
Um auszuschließen, dass es mit dem upgrade Etch -> Lenny zu tun hat (Server war ursprünglich debian40, ich hatte dann von Hand auf 5.0 upgedated) habe ich ihn jetzt mit Lenny nochmal neu aufsetzen lassen. Ausserdem schreibe ich die Performance-Daten jetzt mit munin statt sysstat mit, mal sehen, wie es sich entwickelt...
Mein 2. RPS-1 (Testsystem mit gentoo) läuft (bis jetzt) einwandfrei...
Und auf meinen RPS-2 warte ich seit letztem Samstag...
Zitat von
kro
hofi02 wrote:
> ich habe die selben probleme ca. 1 mal die woche, der server ist dann
> plötzlich nicht mehr erreichbar, gerade eben ist es wieder passiert
Hast du im syslog eine Fehlermeldung?
--
Felix
OVH Team
ja heut ist er wieder gegen mittag kurtz stehen geblieben für ca 10 minuten
in dem zeitraum steht das hier im log.
Code:
[...]
Mar 30 11:11:15 r13879 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 30 11:11:15 r13879 kernel: eth0: Transmit timeout, status 00000004 00000000
Mar 30 11:11:15 r13879 kernel: eth0: Media Link On 100mbps full-duplex
Mar 30 11:11:15 r13879 kernel: eth0: Media Link Off
Mar 30 11:11:15 r13879 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 30 11:11:15 r13879 kernel: eth0: Transmit timeout, status 00000004 00000000
Mar 30 11:11:15 r13879 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 30 11:11:15 r13879 kernel: eth0: Transmit timeout, status 00000004 00000000
Mar 30 11:11:15 r13879 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 30 11:11:15 r13879 kernel: eth0: Transmit timeout, status 00000004 00000000
Mar 30 11:11:15 r13879 kernel: eth0: Media Link On 100mbps full-duplex
Mar 30 11:11:15 r13879 kernel: eth0: Media Link Off
Mar 30 11:11:15 r13879 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 30 11:11:15 r13879 kernel: eth0: Transmit timeout, status 00000004 00000040
Mar 30 11:11:15 r13879 kernel: eth0: Media Link On 100mbps full-duplex
Mar 30 11:11:15 r13879 kernel: eth0: Media Link Off
Mar 30 11:11:15 r13879 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 30 11:11:15 r13879 kernel: eth0: Transmit timeout, status 00000004 00000000
Mar 30 11:11:15 r13879 kernel: eth0: Media Link On 100mbps full-duplex
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9585]: (root) CMD (/usr/local/rtm/bin/rtm 26 > /dev/null 2> /dev/null)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9586]: (root) CMD (run-parts /usr/local/oco/bin/300sec >/dev/null 2>/dev/null)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9587]: (root) CMD (run-parts /usr/local/oco/bin/120sec >/dev/null 2>/dev/null)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9588]: (root) CMD (run-parts /usr/local/oco/bin/60sec >/dev/null 2>/dev/null)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9589]: (tss) CMD (/var/scripts/ts2-cron > /dev/null 2>&1)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9590]: (tmf) CMD (/var/scripts/tmf-cron > /dev/null 2>&1)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9591]: (root) CMD (/usr/local/rtm/bin/rtm 26 > /dev/null 2> /dev/null)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9592]: (root) CMD (run-parts /usr/local/oco/bin/60sec >/dev/null 2>/dev/null)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9593]: (tss) CMD (/var/scripts/ts2-cron > /dev/null 2>&1)
Mar 30 11:11:15 r13879 /USR/SBIN/CRON[9594]: (tmf) CMD (/var/scripts/tmf-cron > /dev/null 2>&1)
Mar 30 11:11:15 r13879 iscsid: connect failed (113)
Mar 30 11:11:16 r13879 last message repeated 130 times
Mar 30 11:11:16 r13879 iscsid: connection1:0 is operational after recovery (133 attempts)
[...]
ich bin auf iscsi25.rps.ovh.net und habe ubuntu 8.04 installiert falls das weiterhilft
Zitat von
kro
ovh4724 wrote:
> Ist das Problem RPS-spezifisch?
Ja, betrifft nur RPS mit iSCSI und Debian Lenny Beta.
Dann hätte mein Server ja eigentlich nicht stehen bleiben dürfen, denn das ursprünglich beauftragte Image war "debian40", das dist-upgrade auf Lenny hab ich von Hand gemacht.
Aber bis jetzt läuft alles *klopfaufholz* Ich hoffe ja, dass der 50GB RPS bald kommt, dann zieh ich eh um. (Wobei ich ja eigentlich erst noch RPS-1 vs. RPS-2 testen wollte...) naja mal sehen
ovh4724 wrote:
> Ist das Problem RPS-spezifisch?
Ja, betrifft nur RPS mit iSCSI und Debian Lenny Beta.
> Gibt es irgendwo einen Bug-Report?
http://travaux.ovh.net/?do=details&id=2980
--
Felix
OVH Team
Jenstheclown
27.03.09, 15:18
Zitat von
hofi02
ich habe die selben probleme ca. 1 mal die woche, der server ist dann plötzlich nicht mehr erreichbar, gerade eben ist es wieder passiert
Schließe mich an. Mein server ist gestern auch einfach stehen geblieben, anpingbar war er aber noch
hofi02 wrote:
> ich habe die selben probleme ca. 1 mal die woche, der server ist dann
> plötzlich nicht mehr erreichbar, gerade eben ist es wieder passiert
Hast du im syslog eine Fehlermeldung?
--
Felix
OVH Team
ovh4724 wrote:
> Ich habe das gleiche Problem. Gibt es ein paar mehr Informationen zu
> der Ursache und der Lösung?
Wir spielen bei der Installation distributionsübergreifend die gleichen
binaries ein, hier wurde das dazu passende initskript vergessen.
> Das manuelle Überschreiben einer Datei aus einem Debian-Paket mag ein
> Workaround aber keine Dauerlösung sein.
Du kannst das Debian-Paket entfernen.
--
Felix
OVH Team
Zitat von
markusb
Ich hatte das Problem mit Debian 5 auch. Aber steht ja auch BETA dran
Bei gentoo hab ich keine Probleme festgestellt.
Ich hab ja grade noch ne Bestellung laufen - von wegen 50GB und so... - Da werde ich mal gentoo ausprobieren. Hab ich bis jetzt nur auf dem Desktop genutzt, ein gentoo-Server ist Neuland für mich, aber das wird schon klappen...
Ich hatte das Problem mit Debian 5 auch. Aber steht ja auch BETA dran
Bei gentoo hab ich keine Probleme festgestellt.
Zitat von
hofi02
ich habe die selben probleme ca. 1 mal die woche, der server ist dann plötzlich nicht mehr erreichbar, gerade eben ist es wieder passiert
Zitat von
svenr
Ich hab das Problem auch das mal nach paar Tagen RPS1 weg ist.
Na, immerhin bin ich nicht alleine \o/
Hilft keinem wirklich weiter, tröstet aber. Ich warte auf den nächsten Ausall, vielleicht helfen die sar-Daten dann ja ein bisschen weiter.
Ich hab das Problem auch das mal nach paar Tagen RPS1 weg ist.
ich habe die selben probleme ca. 1 mal die woche, der server ist dann plötzlich nicht mehr erreichbar, gerade eben ist es wieder passiert
Zitat von
kro
thorwin wrote:
>> > mein RPS-1 ist mir jetzt zum 2. Mal in FOlge mitten in der Nacht
>> > einfach stehen geblieben.
Fehler gefunden, fixen geht wie folgt:
wget ftp://ftp.ovh.net/made-in-ovh/rps/open-iscsi -O /etc/init.d/open-iscsi && chmod +x /etc/init.d/open-iscsi && /etc/init.d/open-iscsi restart
Ich habe das gleiche Problem. Gibt es ein paar mehr Informationen zu der Ursache und der Lösung?
Das manuelle Überschreiben einer Datei aus einem Debian-Paket mag ein Workaround aber keine Dauerlösung sein.
Ist das Problem RPS-spezifisch? Gibt es irgendwo einen Bug-Report?
Zitat von
kro
thorwin wrote:
>> > mein RPS-1 ist mir jetzt zum 2. Mal in FOlge mitten in der Nacht
>> > einfach stehen geblieben.
Fehler gefunden, fixen geht wie folgt:
wget ftp://ftp.ovh.net/made-in-ovh/rps/open-iscsi -O /etc/init.d/open-iscsi && chmod +x /etc/init.d/open-iscsi && /etc/init.d/open-iscsi restart
Hab ich jetzt mal gemacht, obwohl ich auf Anhieb den Unterschied zwischen den Skripten nicht gesehen habe (bis auf ein kill -9 im "stop"-Teil).
Habe inzwischen auch (auf Anraten des Kundendienstes) mal einen Systemtest im Rescue-Mode durchgeführt, da war alles ok.
Ich schreibe jetzt minütlich mal sysstat-Daten mit, evtl. bringt mich das ja auch noch weiter, wenn die Kiste wieder stehen bleiben sollte...
Danke und Gruß, thorwin
thorwin wrote:
>> > mein RPS-1 ist mir jetzt zum 2. Mal in FOlge mitten in der Nacht
>> > einfach stehen geblieben.
Fehler gefunden, fixen geht wie folgt:
wget
ftp://ftp.ovh.net/made-in-ovh/rps/open-iscsi -O /etc/init.d/open-iscsi && chmod +x /etc/init.d/open-iscsi && /etc/init.d/open-iscsi restart
--
Felix
OVH Team
Zitat von
kro
thorwin wrote:
> mein RPS-1 ist mir jetzt zum 2. Mal in FOlge mitten in der Nacht
> einfach stehen geblieben.
Welche Servernummer? (steht im Manager)
Was sind die letzten Meldungen im syslog?
Das ist der Server:
Rack: 23A15
Nummer: 73170
Version: 1
iSCSI Server: iscsi47.rps.ovh.net
Und die letzte Meldung im syslog ist immer
"mephisto kernel: IPv6 addrconf: prefix with wrong length 56"
Das eth0 hat aber eine Adresse mit prefix /64 (eben die, die im Manager steht).
OS ist Debian Lenny, das ursprüngliche Image ist debian40.
Gruß, thorwin
thorwin wrote:
> mein RPS-1 ist mir jetzt zum 2. Mal in FOlge mitten in der Nacht
> einfach stehen geblieben.
Welche Servernummer? (steht im Manager)
Was sind die letzten Meldungen im syslog?
--
Felix
OVH Team
Hallo,
mein RPS-1 ist mir jetzt zum 2. Mal in FOlge mitten in der Nacht einfach stehen geblieben. Irgendwann zwischen 0:00 und 0:20 kam nichts mehr und ich musste das System per Webinterface rebooten. Auf Dauer wird das lästig... Hat jemand ähnliche Probleme? Ich habe jetzt nochmal den (Netboot-)Kernel gewechselt, vorher war es 2.6.28 mit IPv6 jetzt ist es 2.6.27.10 incl. GRSEC & IPv6. Sind irgendwelche Probleme mit dem 2.6.28er bekannt?
Danke und Gruß,
thorwin