OVH Community, your new community space.

iscsi hängt und kommt nicht wieder


Shaun
29.06.09, 21:04
Ich habe die segfaults extra mit aufgenommen, da sie zum ersten mal direkt nach dem iscsi Problem auftreten. Das ganze geht auch im Log (auf dem USB Stick) so weiter (iscsi errors, segfaults,...). Die Maschine lässt sich wie üblich pingen, aber ein login ist nicht möglich.
Nach einem reboot geht alles (erstmal) wieder.

kro
29.06.09, 13:10
Shaun wrote:
> Jun 24 07:12:36 kernel: sh[4766]: segfault at b7500950 ip b80c1ad4 sp bfcdc1f4 error 6 in ld-2.7.so[b80c1000+1a000]
> Jun 24 07:12:44 kernel: sh[7790]: segfault at b7500950 ip b7fa8ad4 sp bfdc32e4 error 6 in ld-2.7.so[b7fa8000+1a000]<6>nice[7791]: segfault at b7500950 ip b7ef9ad4 sp bff12e84 error 6 in ld-2.7.so[b7ef9000+1a000]
> Jun 24 07:12:44 kernel: nice[7793]: segfault at b7500950 ip b7f8dad4 sp bfaa88c4 error 6 in ld-2.7.so[b7f8d000+1a000]


Die segfaults da sehen für mich nicht nach einem iSCSI-Problem aus, eher eine
fehlende/kaputte library oder im extremen Fall ein Problem mit dem RAM.
Letzteres kannst du im Rescue über das Webinterface überprüfen lassen.
--
Felix
OVH Team

ts-onlyfree
29.06.09, 07:19
hab mir das jetzt auch mehrere wochen angeschaut ! alle paar tage kaggt die kiste einfach ab... ovh sagt es wäre kein problem mit dem iscsi sondern muss ein anderes problem sein... auf dem rps läuft garnichts außer einem kleinen apache der keine last verursacht und trotzdem hauts die kiste immer wieder weg

dieses "verhalten" ist einfach nicht tragbar... da ist jeder popelige vserver besser -.-

wird der letzte monat sein wo ich kunde bei ovh bin... die jungs haben schwer nachgelassen.... anfangs lief der rps wirklich super (bin rps-kunde fast seit anfang an) ... aber in den letzten 3 monaten macht das ding nur noch mist... schmiert ab und wird einfach in rescue gebooted... aber was will man bei dem preis auch erwarten...

rps ist für mich beta-ware und die kunden sind der live-test -.-

Shaun
28.06.09, 21:37
So, iscsi ging jetzt ein paar Tage und zickt nun wieder rum.

Dieses mal sieht es noch seltsamer aus:
Code:
Jun 24 07:12:36  kernel: session1: session recovery timed out after 86400 secs
Jun 24 07:12:36  kernel: sd 2:0:0:0: [sda] Unhandled error code
Jun 24 07:12:36  kernel: sd 2:0:0:0: [sda] Result: hostbyte=DID_TRANSPORT_FAIL
FAST driverbyte=DRIVER_OK,SUGGEST_OK
...
Jun 24 07:12:36  kernel: sh[4766]: segfault at b7500950 ip b80c1ad4 sp bfcdc1f4 error 6 in ld-2.7.so[b80c1000+1a000]
...
Jun 24 07:12:36  kernel: __journal_remove_journal_head: freeing b_committed_da
ta
...
Jun 24 07:12:36  kernel: attempt to access beyond end of device
Jun 24 07:12:36  kernel: sda1: rw=0, want=15083467600, limit=10233342
...
Jun 24 07:12:44  kernel: __ratelimit: 196 callbacks suppressed
Jun 24 07:12:44  kernel: attempt to access beyond end of device
Jun 24 07:12:44  kernel: sda1: rw=0, want=15083467600, limit=10233342
Jun 24 07:12:44  kernel: sh[7790]: segfault at b7500950 ip b7fa8ad4 sp bfdc32e4 error 6 in ld-2.7.so[b7fa8000+1a000]<6>nice[7791]: segfault at b7500950 ip b7ef9ad4 sp bff12e84 error 6 in ld-2.7.so[b7ef9000+1a000]
Jun 24 07:12:44  kernel:
Jun 24 07:12:44  kernel: nice[7793]: segfault at b7500950 ip b7f8dad4 sp bfaa88c4 error 6 in ld-2.7.so[b7f8d000+1a000]
Ich werde den Server auslaufen lassen. Eigentlich finde ich iscsi ja klasse, aber wenn die Technik so buggy ist...

chrit
09.06.09, 16:13
Diese Aussage mache ich extra nicht, aber ein fakt ist ein fakt

Shaun
09.06.09, 15:58
Zitat Zitat von chrit
1. NFS gibt es noch und es performt besser aber der Timestamp vom NFS ist unsyncron, was etwas sehr stressig ist.
Du meinst OVH weis nicht wie man NTP bedient?

chrit
09.06.09, 10:12
Du meinste die ausbrems-Evolution. Ich gebe meinen Cel215 gerne her, im Tausch gegen nen Athlon X2 BE-2300, weil die Atoms sind ja sowas von träge. (ich hab hier neben mir nen 330er wie im RPS II und den alten Cel 215 wie auch in den alten RPS I drinnen war. Die Leistungsaufnahme entspricht leider auch der Rechenleistung [der alte ist besser])

1. NFS gibt es noch und es performt besser aber der Timestamp vom NFS ist unsyncron, was etwas sehr stressig ist.

2. Wenn ich mit einem Magebyte pro Sekunde leben müsste, würde ich auch sterben (iSCSI Standard ~1MB/s | iSCSI Premium ~4MB/s | iSCSI Buisness ~10 MB/s)

S1lv3R
08.06.09, 18:23
Zitat Zitat von pendulum
NFS gibs nichmehr seit der letzen "Evolution" der RPS.

Die subtilen Anführungsstriche mit dem unterschwelligen, mitschwingenden vielleicht leicht ironischen Unterton bei "Evolution" - mag wohl nur der langjährige und erfahrene RPS-Benutzer zu interpretieren wissen.

thinkz
06.06.09, 15:36
NFS kann noch bei der Reinstallation benutzt werden, daher RPS reinstallieren Shaun...

pendulum
06.06.09, 15:06
NFS gibs nichmehr seit der letzen "Evolution" der RPS.

Shaun
06.06.09, 14:07
Gestern Abend ist mein RPS-I schon wieder stehen geblieben, - das erste mal mit dem neuen Kernel 2.6.29.3.

Letzte brauchbaren Einträge im Syslog (auf dem USB-Stick):
Code:
Jun  5 19:07:36 MyServer kernel: connection1:0: detected conn error (1011)
Jun  5 19:07:37 MyServer iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Vorher ist der Server immerhin 5 Tage stabil gelaufen.
Wie ich allerdings in den alten Logs sehe, wurde der beta-Kernel noch mal überarbeitet.
Der "alte" 2.6.29.3 ist bei mir nie stehen geblieben.

Mit dieser "Zuverlässigkeit" ist das Produkt leider für mich nicht brauchbar.
Kann ich das komplette System auf NFS umstellen? Was muss ich dafür tun?

S1lv3R
05.06.09, 22:26
Ah ok, im Manager steht es unter Dienstleistungen --> Netboot allerdings andersrum:"Boot auf Ihrer Festplatte (hd): Dies ist die Standardoption.[...]", daher auch die dumme Frage.

sh-3.2# uname -a
Linux r18275.ovh.net 2.6.29.3-rt12-xxxx-rt12-ipv6-32 #2 SMP PREEMPT RT Fri May 29 15:41:32 UTC 2009 i686 GNU/Linux

Bootet überraschend schnell ... mal schauen was draus wird - beobachte es in den nächsten Tagen mal.

Kleines Problem noch ... nach dem Reboot ging der Webserver nicht mehr, hab mit htop geschaut und der Prozess lief. Wollte sich aber weder starten noch stoppen lassen (scheinbar wurde beim booten keine PID-Datei erzeugt). Nach dem ich den Prozess manuell abgeschossen und wieder gestartet habe lief er wieder. Hat vielleicht jemand nen Tipp woran das liegen kann? Weiss nicht ob die unten angehängten iscsi-Meldungen im syslog was damit zu tun haben können, oder ob diese beim Bootprozess so normal sind. Im Apache error.log steht leider nichts interessantes hierzu.

---------------
sh-3.2# htop
sh-3.2# /etc/init.d/apache2 stop
* Stopping web server apache2
httpd (no pid file) not running [ OK ]
sh-3.2# /etc/init.d/apache2 start
* Starting web server apache2
httpd (pid 3759) already running [ OK ]
sh-3.2# kill 3759
sh-3.2# /etc/init.d/apache2 start
* Starting web server apache2 [ OK ]

-------------

sh-3.2# cat /var/log/syslog | grep iscsi | grep "Jun 5 23:"
Jun 5 23:21:41 r18275 kernel: Kernel command line: root=/dev/ram0 initrd=iscsi/initrd-iscsi.img libusual.bias=ub console=tty0 BOOT_IMAGE=rps/bzImage-2.6-xxxx-rt-ipv6-32
Jun 5 23:21:41 r18275 kernel: iscsi: registered transport (tcp)
Jun 5 23:22:40 r18275 iscsid: iSCSI logger with pid=3383 started!
Jun 5 23:22:41 r18275 iscsid: transport class version 2.0-870. iscsid version 2.0-870
Jun 5 23:22:41 r18275 iscsid: iSCSI daemon with pid=3384 started!
Jun 5 23:22:41 r18275 iscsid: Could not read data from db. Using default and currently negotiated values
Jun 5 23:22:44 r18275 iscsid: connection1:0 is operational after recovery (1 attempts)

kro
05.06.09, 17:54
S1lv3R wrote:
> du meinst ich soll soll auf Netboot mit dem 2.6.29 beta Kernel
> umstellen?


Ja.

> Funktioniert das garantiert problemlos von HDD-Kernel auf Netboot
> umzustellen (habe diese Funktion noch nie ausprobiert


RPS sind standardmässig auf netboot eingestellt. Wenn du daran nichts geändert
hast, ist das bei deinem auch so.
--
Felix
OVH Team

S1lv3R
05.06.09, 17:15
Hallo,

du meinst ich soll soll auf Netboot mit dem 2.6.29 beta Kernel umstellen?

Funktioniert das garantiert problemlos von HDD-Kernel auf Netboot umzustellen (habe diese Funktion noch nie ausprobiert - gibt es Stolpersteine)? ... Werde es sonst mal heute Nacht ausprobieren ... am Freitag um 18:30 Uhr was am Kernel zu basteln ist mir zu hart.

Gruß,
S1lv3R

kro
05.06.09, 11:58
S1lv3R wrote:
> sh-3.2# md5sum /sbin/iscsid
> f62ba3b6e34e1d6b0c94f4c585bcf1cf /sbin/iscsid
> sh-3.2# md5sum /sbin/iscsiadm
> a52e5e8517386a736d148b772c2f6756 /sbin/iscsiadm


Das sollte also nicht die Ursache sein. Kannst du mal den 2.6.29-Kernel
probieren?
--
Felix
OVH Team

MoD.666
05.06.09, 10:46
Selbes Problem auf einem RPS2 Nummer 65475 auf Filer 45. System ist Debian Lenny, aktuell gepatcht und bei allen Kerneln. Der Beta-Kernel lief wenigstens 2 Tage und 7 Stunden, alle anderen wesentlich weniger ;(
Da ich den Server in mehreren ssh-Sitzungen monitore, ist mir noch etwas aufgefallen:

Kurz vor dem Ausfall, quasi reproduzierbar, geht der Load auf ca.20 hoch (obwohl da nicht viel drauf läuft!), dann steigen nach und nach die Dienste aus bzw. antworten verzögert und zum Schluss werden Daten mit ca. 20MBit/s. an den Filer geschickt (iftop). Gerade letzteres macht mich sehr stutzig, denn der Zustand hält ca. 10 Minuten an, bevor der Server sich ganz verabschiedet.
Wie bei allen anderen auch keine Einträge im Logfile.
Nach einem Hardreboot dauert es teilweise bis zu einer Stunde bis alle Dienste wieder laufen. Server ist innerhalb von 1 Minute pingbar, aber SSH etc. kommen sehr langsam nach und nach wieder...

xnor
05.06.09, 10:42
Zitat Zitat von S1lv3R
sh-3.2# md5sum /sbin/iscsid
f62ba3b6e34e1d6b0c94f4c585bcf1cf /sbin/iscsid

sh-3.2# md5sum /sbin/iscsiadm
a52e5e8517386a736d148b772c2f6756 /sbin/iscsiadm
Die habe ich auch - und immer noch regelmäßige Abstürze...

Grüße

Joern

S1lv3R
05.06.09, 06:29
Guten Morgen,
mache ich gerne.

sh-3.2# md5sum /sbin/iscsid
f62ba3b6e34e1d6b0c94f4c585bcf1cf /sbin/iscsid

sh-3.2# md5sum /sbin/iscsiadm
a52e5e8517386a736d148b772c2f6756 /sbin/iscsiadm


Gerade aufgestanden und nicht mit einer guten Nachricht von meinem RPS begrüßt worden, scheinbar war der Server laut ovh Monitoring von 05:10:49 bis 05:18:14 heute Morgen wieder down (kein ping).

----
sh-3.2# cat /var/log/syslog.0 | grep iscsi

Jun 5 05:10:27 r18275 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Jun 5 05:16:27 r18275 iscsid: connect failed (113)
Jun 5 05:16:29 r18275 iscsid: connect failed (113)
Jun 5 05:16:29 r18275 iscsid: connect failed (113)
Jun 5 05:16:31 r18275 iscsid: connect failed (113)
Jun 5 05:16:31 r18275 iscsid: connect failed (113)
Jun 5 05:16:33 r18275 iscsid: connect failed (113)
Jun 5 05:16:35 r18275 iscsid: connect failed (113)
Jun 5 05:16:35 r18275 iscsid: connect failed (113)
Jun 5 05:16:35 r18275 iscsid: connect failed (113)
Jun 5 05:16:35 r18275 iscsid: connect failed (113)
Jun 5 05:16:35 r18275 iscsid: connection1:0 is operational after recovery (61 attempts)
Jun 5 05:51:48 r18275 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Jun 5 05:51:52 r18275 iscsid: connection1:0 is operational after recovery (1 attempts)
Jun 5 05:52:36 r18275 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Jun 5 05:52:37 r18275 iscsid: connection1:0 is operational after recovery (1 attempts)

(Seit 05:52 aber nichts mehr mit iscsi im Log)

kro
04.06.09, 22:34
S1lv3R wrote:
> sh-3.2# uname -a
> Linux r18275.ovh.net 2.6.27.10-grsec-xxxx-grs-ipv4-32 #4 SMP Wed Feb 18


kannst du mal die Ausgabe von
md5sum /sbin/iscsid
md5sum /sbin/iscsiadm
posten?
--
Felix
OVH Team

S1lv3R
04.06.09, 20:27
Hallo,

habe auch schon länger ein Problem mit meinem RPS I und (wahrscheinlich) dem iscsi. Langsam ist es unerträglich für ein Produktivsystem. Wenn der Webserver 2 Stunden hängt ist das ok, aber in letzter Zeitwar es immer so, dass der Mailserver weiter Emails annimmt und diese im Nirvana verschwinden. Wenn eine Fehlermeldung kommt verstehen das die Kunden, aber erzähl denen, dass die Mail zwar ohne Fehler vom Server angenommen wird, aber dann im Nirvana verschwindet.

Jedes mal das gleiche Symptom ... Server ist nicht erreichbar bis zum Hardreset über das Webinterface. Laut Logdatei ist die iscsi Verbindung nur kurz weg - aber scheinbar fängt sich der Server danach nicht mehr. Heut Morgen um 7:15 aufgestanden und der Server war komplett weg (kein Ping) ...

Hat vielleicht irgend jemand eine Idee? Sonst muss ich den RPS wohl leider aufgeben, ist ja kein Zustand so.


Gruß,
S1lv3R

-------------------------
cat /var/log/syslog.0 | grep iscsi

Jun 4 06:36:45 r18275 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Jun 4 06:37:22 r18275 iscsid: connection1:0 is operational after recovery (2 attempts)

-------------------------
Rack: 07D15
Nummer: 33814
Version: 1
iSCSI Server: iscsi46.rps.ovh.net
System (OS) : ubuntu804-server

---------------------
sh-3.2# uname -a
Linux r18275.ovh.net 2.6.27.10-grsec-xxxx-grs-ipv4-32 #4 SMP Wed Feb 18 16:30:23 UTC 2009 i686 GNU/Linux

kro
31.05.09, 11:20
Shaun wrote:
> Kann uns jetzt geholfen werden?


Ja, nimm einen anderen Kernel. Es scheint hier tatsächlich ein Problem zwischen
iscsid, dem Kernel und debian's libc zu geben, der jedoch nur mit dem 2.6.28.4
auftritt.
--
Felix
OVH Team

Shaun
31.05.09, 09:53
Nachdem mein RPS-I mit dem beta-Kernel 5 Tage keine Probleme zeigte, habe ich noch mal den 2.6.28.4 installiert. Außerdem lasse ich syslog auf den USB-Stick schreiben.

=> Ich konnte jetzt ein paar Logs vom iscsi Hänger einfangen:

Code:
May 30 23:15:31 MyHostname kernel: connection1:0: ping timeout of 5 secs expired, last rx 91179055, last ping 91180305, now 91181555
May 30 23:15:31 MyHostname kernel: connection1:0: detected conn error (1011)
May 30 23:15:32 MyHostname iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
May 30 23:15:39 MyHostname kernel: ------------[ cut here ]------------
May 30 23:15:39 MyHostname kernel: WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0x1f0/0x200()
May 30 23:15:39 MyHostname kernel: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
May 30 23:15:39 MyHostname kernel: Pid: 0, comm: swapper Not tainted 2.6.28.4-xxxx-std-ipv6-32 #2
May 30 23:15:39 MyHostname kernel: Call Trace:
May 30 23:15:39 MyHostname kernel: [] warn_slowpath+0x6a/0x90
May 30 23:15:39 MyHostname kernel: [] autoremove_wake_function+0x1b/0x50
May 30 23:15:39 MyHostname kernel: [] __wake_up_common+0x43/0x70
May 30 23:15:39 MyHostname kernel: [] __wake_up+0x3e/0x60
May 30 23:15:39 MyHostname kernel: [] clear_bdi_congested+0x42/0x50
May 30 23:15:39 MyHostname kernel: [] read_tsc+0x6/0x40
May 30 23:15:39 MyHostname kernel: [] getnstimeofday+0x51/0x110
May 30 23:15:39 MyHostname kernel: [] nommu_map_single+0x50/0xd0
May 30 23:15:39 MyHostname kernel: [] getnstimeofday+0x51/0x110
May 30 23:15:39 MyHostname kernel: [] ktime_get+0x18/0x40
May 30 23:15:39 MyHostname kernel: [] strlcpy+0x1f/0x60
May 30 23:15:39 MyHostname kernel: [] netdev_drivername+0x2f/0x40
May 30 23:15:39 MyHostname kernel: [] dev_watchdog+0x1f0/0x200
May 30 23:15:39 MyHostname kernel: [] posix_cpu_timer_set+0x2c9/0x440
May 30 23:15:39 MyHostname kernel: [] read_tsc+0x6/0x40
May 30 23:15:39 MyHostname kernel: [] getnstimeofday+0x51/0x110
May 30 23:15:39 MyHostname kernel: [] lapic_next_event+0x10/0x20
May 30 23:15:39 MyHostname kernel: [] clockevents_program_event+0xa1/0x160
May 30 23:15:39 MyHostname kernel: [] dev_watchdog+0x0/0x200
May 30 23:15:39 MyHostname kernel: [] run_timer_softirq+0xf8/0x1c0
May 30 23:15:39 MyHostname kernel: [] tick_dev_program_event+0x32/0xb0
May 30 23:15:39 MyHostname kernel: [] __do_softirq+0x8f/0x150
May 30 23:15:39 MyHostname kernel: [] do_softirq+0x3d/0x50
May 30 23:15:39 MyHostname kernel: [] irq_exit+0x5d/0x80
May 30 23:15:39 MyHostname kernel: [] smp_apic_timer_interrupt+0x58/0x90
May 30 23:15:39 MyHostname kernel: [] apic_timer_interrupt+0x28/0x30
May 30 23:15:39 MyHostname kernel: [] mwait_idle+0x2f/0x40
May 30 23:15:39 MyHostname kernel: [] cpu_idle+0x64/0xc0
May 30 23:15:39 MyHostname kernel: ---[ end trace 5c712348c786f65b ]---
Der iscsid versucht anschließend alle paar Sekunden wieder auf seinen Storage (iscsi64.rps.ovh.net) zuzugreifen, scheitert jedoch aus irgendeinem Grund.
Kann uns jetzt geholfen werden?

xnor
30.05.09, 10:02
Zitat Zitat von kro
Kannst du mal den Beta-Kernel (2.6.29) ausprobieren?
Hatte ich, auch damit ist er abgestürzt. Jetzt verwende ich grade auf anraten des Supportes den Kernel mit GRSEC. Mal sehen, was das wird...

Joern

kro
29.05.09, 18:36
filewalker wrote:
> Das selbe hier (iscsi50.rps.ovh.net):


Nein, überhaupt nicht das gleiche: die Verbindung wurde verloren, aber auch
wieder hergestellt.
--
Felix
OVH Team

filewalker
29.05.09, 18:18
Das selbe hier (iscsi50.rps.ovh.net):
Code:
May 29 08:08:27 phoenix kernel: connection1:0: ping timeout of 5 secs expired, last rx 1153540272, last ping 1153541522, now 1153542772
May 29 08:08:27 phoenix kernel: connection1:0: detected conn error (1011)
May 29 08:08:28 phoenix iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
May 29 08:09:05 phoenix iscsid: connect failed (113)
May 29 08:09:11 phoenix iscsid: connect failed (113)
May 29 08:09:18 phoenix iscsid: connect failed (113)
May 29 08:09:24 phoenix iscsid: connect failed (113)
May 29 08:09:30 phoenix iscsid: connect failed (113)
May 29 08:09:36 phoenix iscsid: connect failed (113)
May 29 08:09:43 phoenix iscsid: connect failed (113)
May 29 08:09:49 phoenix iscsid: connect failed (113)
May 29 08:09:55 phoenix iscsid: connect failed (113)
May 29 08:10:01 phoenix iscsid: connect failed (113)
May 29 08:10:07 phoenix iscsid: connect failed (113)
May 29 08:10:14 phoenix iscsid: connect failed (113)
May 29 08:10:20 phoenix iscsid: connect failed (113)
May 29 08:10:26 phoenix iscsid: connect failed (113)
May 29 08:10:32 phoenix iscsid: connect failed (113)
May 29 08:10:39 phoenix iscsid: connect failed (113)
May 29 08:10:45 phoenix iscsid: connect failed (113)
May 29 08:10:51 phoenix iscsid: connect failed (113)
May 29 08:10:57 phoenix iscsid: connect failed (113)
May 29 08:11:04 phoenix iscsid: connect failed (113)
May 29 08:11:10 phoenix iscsid: connect failed (113)
May 29 08:11:16 phoenix iscsid: connect failed (113)
May 29 08:11:22 phoenix iscsid: connect failed (113)
May 29 08:11:28 phoenix iscsid: connect failed (113)
May 29 08:11:35 phoenix iscsid: connect failed (113)
May 29 08:11:41 phoenix iscsid: connect failed (113)
May 29 08:11:47 phoenix iscsid: connect failed (113)
May 29 08:11:53 phoenix iscsid: connect failed (113)
May 29 08:12:00 phoenix iscsid: connect failed (113)
May 29 08:12:06 phoenix iscsid: connect failed (113)
May 29 08:12:12 phoenix iscsid: connect failed (113)
May 29 08:14:02 phoenix iscsid: connect failed (113)
May 29 08:14:07 phoenix iscsid: connect failed (113)
May 29 08:14:14 phoenix iscsid: connect failed (113)
May 29 08:14:20 phoenix iscsid: connect failed (113)
May 29 08:14:26 phoenix iscsid: connect failed (113)
May 29 08:14:32 phoenix iscsid: connect failed (113)
May 29 08:14:39 phoenix iscsid: connect failed (113)
May 29 08:14:45 phoenix iscsid: connect failed (113)
May 29 08:14:51 phoenix iscsid: connect failed (113)
May 29 08:14:55 phoenix iscsid: connect failed (113)
May 29 08:15:00 phoenix iscsid: connection1:0 is operational after recovery (46 attempts)

kro
29.05.09, 17:06
xnor wrote:
> Was kann man jetzt noch machen?


Kannst du mal den Beta-Kernel (2.6.29) ausprobieren?
--
Felix
OVH Team

piespy
29.05.09, 16:48
Hardware-Tests vielleicht? CPU burnout Test und Speichertest probieren.

Man könnte auch versuchen, einen Watchdog einzurichten. Falls der Kernel nicht komplett abgestürzt ist, wird dann das System automatisch neugestartet wenn der Watchdog Prozess nicht mehr regelmässig in das watchdog device schreibt.

Behebt zwar das Problem nicht, aber immerhin wird er dann so schnell wie möglich automatisch neugestartet.

[edit]Ob der iscsi-Daemon korrekt funktioniert, konnte man übrigens in den letzten Tagen gut feststellen da alle iscsi-Devices rebootet worden sind:
Code:
/var/log/daemon.log:May 28 12:41:22 r11574 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
/var/log/daemon.log:May 28 12:41:24 r11574 iscsid: connect failed (111)
/var/log/daemon.log:May 28 12:41:28 r11574 iscsid: connect failed (111)
[...]
/var/log/daemon.log:May 28 12:42:37 r11574 iscsid: connect failed (111)
/var/log/daemon.log:May 28 12:44:48 r11574 iscsid: connection1:0 is operational after recovery (25 attempts)

xnor
29.05.09, 08:48
...wurde gemacht.
Und auch der aktuelle Kernel aus dem Netboot war beteiligt.
Und siehe da: auch dort war das Log tod.

Wenn ich das alles also richtig verstehe ist iscsi tatsächlich unschuldig und die Kiste bleibt einfach stehen. Manchmal. Ohne erkennbares Muster.

Was kann man jetzt noch machen?

Grüße

joern

xnor
26.05.09, 19:18
Zitat Zitat von kro
xnor wrote:[color=blue]
Zur weiteren Fehlersuche: kannst du eventuell (einen Teil) des USB-Sticks
formatieren und mounten, und darauf loggen lassen?
Gute Idee! Wird gemacht.

Grüße

Joern

kro
26.05.09, 11:02
xnor wrote:
> Der Verdacht kam mir auch, nachdem auch das loggen auf eine entfernte
> Maschine nicht funktionierte bei einem Absturz.


Zur weiteren Fehlersuche: kannst du eventuell (einen Teil) des USB-Sticks
formatieren und mounten, und darauf loggen lassen?
--
Felix
OVH Team

kro
26.05.09, 10:28
xnor wrote:
> OVH: Macht was draus. Nehmt Ihr uns war oder sind Euch Kunden egal?
> Welchen Weg sollen wir ansonsten benutzen um mit Euch in Kontakt zu
> treten? Wir wollen konstruktiv dran arbeiten und nicht ignoriert
> werden!


Selbstverständlich arbeiten wir dran und ignorieren euch nicht. Aber wie ihr
selber festgestellt habt ist der Fehler weder gewollt reproduzierbar, noch
sonderlich gut zu diagnostizieren (keine logs). Auf eigenen RPS1 mit
standard-Debianinstallationen konnte das von euch gemeldete Verhalten nicht
beobachtet werden.
--
Felix
OVH Team

xnor
26.05.09, 09:49
ach und: heute Morgen mal wieder stehen geblieben.
May 26 05:00:01 allmers /USR/SBIN/CRON[3780]: (root) CMD (/usr/local/rtm/bin/rtm 32 > /dev/null 2> /dev/null)
May 26 05:00:02 allmers imapd: Disconnected, ip=[::ffff:94.23.48.251], time=1
May 26 09:36:34 allmers kernel: imklog 3.18.6, log source = /proc/kmsg started.
May 26 09:36:34 allmers kernel: BIOS EBDA/lowmem at: 0009fc00/0009e800
May 26 09:36:34 allmers kernel: Initializing cgroup subsys cpuset
May 26 09:36:34 allmers kernel: Linux version 2.6.28.4-xxxx-std-ipv6-32 (root@kernel-32.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1) ) #2 SMP Wed Feb 18 16:36:08 UTC 2009

xnor
25.05.09, 16:06
Zitat Zitat von chems
Seltsam war auch, dass die ersten RPS-I waren, der jetzige RPS-II.
soweit scheint es sich herauskristalliesiert zu haben: nur RPS-1, nie RPS-2, nicht alle RPS-1.
Man kann das Problem durch wechseln der Hardwarenode loswerden, scheinbar.

OVH: Macht was draus. Nehmt Ihr uns war oder sind Euch Kunden egal? Welchen Weg sollen wir ansonsten benutzen um mit Euch in Kontakt zu treten? Wir wollen konstruktiv dran arbeiten und nicht ignoriert werden!

Grüße

Joern

chems
25.05.09, 14:46
Zitat Zitat von xnor
wenn ich das lese, was chems geschrieben hat ("RPS wechseln") dann wäre ich mir ja gar nicht mehr so sicher, dass es wirklich (nur) an iscsi liegt. Vielleicht ja auch an irgendwelcher Hardware.
Der Verdacht kam mir auch, nachdem auch das loggen auf eine entfernte Maschine nicht funktionierte bei einem Absturz.
Der Verdacht liegt nahe... Oder man müsste schauen, welche RPS genau es sind, und ob es vielleicht an internen Routern liegt. Das interessante ist, dass alle Server die ich habe (es gibt ja einige, die nicht bei OVH sind), mit der gleichen Konfiguration laufen, und nur bei den ersten 2 RPS gab es das Problem.

Seltsam war auch, dass die ersten RPS-I waren, der jetzige RPS-II.

xnor
25.05.09, 11:22
wenn ich das lese, was chems geschrieben hat ("RPS wechseln") dann wäre ich mir ja gar nicht mehr so sicher, dass es wirklich (nur) an iscsi liegt. Vielleicht ja auch an irgendwelcher Hardware.
Der Verdacht kam mir auch, nachdem auch das loggen auf eine entfernte Maschine nicht funktionierte bei einem Absturz.

trinec
25.05.09, 11:12
Ich habe auf einem RPS1 & RPS3 einen selbstgebauten Kernel mit OpenVZ patches laufen, jedoch verwende ich die selbe initrd - diese Probleme kann ich jedoch nicht nachvollziehen - hier läuft alles super und keine Ausfälle. An der initrd wird es wohl nicht liegen...

Shaun
25.05.09, 10:29
Mein RPS-I läuft jetzt mal wieder seit 3 Tagen stabil mit dem beta-Kernel. Die iscsid Version ist zwar gleich geblieben, aber vielleicht hat sich ja was anderes wichtiges geändert.
Kann das Ergebnis jemand bestätigen, oder ist das bei mir nur Zufall?

Zitat Zitat von xnor
So gut ich das RPS-Konuept finde und so gut es zu meinem Bedarf passt, werde ich OVH nicht noch mehr Umsatz bescheren weil deren Support unwillig/unfähig/unerlaubt ist das Problem zu lösen.
Da kann ich dir zu 100% zustimmen. Wenn der Support so ignorant ist kann man das Problem nur durch Kündigung lösen.

xnor
25.05.09, 08:09
Zitat Zitat von chems
Ein Tipp an Alle: Macht es so,dass ihr euch einen Migrations-RPS bestellt. Nach dem 2. Wechsel hatte ich nen Server erwischt, der auf einmal problemlos lief.
So gut ich das RPS-Konzept finde und so gut es zu meinem Bedarf passt, werde ich OVH nicht noch mehr Umsatz bescheren weil deren Support unwillig/unfähig/unerlaubt ist das Problem zu lösen.

Das ist ein deutlich falsches Signal. Ich bezhale mit echtem Geld und erwarte ein bestimmtes Maß an Leistung dafür. Wenn OVH nicht in der Lage / Willens ist das zu erbringen dann wollen sie uns nicht als Kunden behalten.

Joern

chems
24.05.09, 19:42
Ich war auch kurz davor OVH zu verlassen, da ich nach Tagen immer die Antwort bekam, dass der Filer läuft und in meinen Logs nichts zu finden ist.

Der Hinweis, dass die Logs nicht weitergeführt werden, wenn die Verbindung down geht, wurde immer wieder ignoriert, obwohl ich es selbst ganz groß schrieb.

Es ist zwar nett, dass der Support uns hier auf den Technischen Support verweist, bringt aber nix, wenn der einem nie weiter hilft, und das Problem immer weiter besteht.

Ein Tipp an Alle: Macht es so,dass ihr euch einen Migrations-RPS bestellt. Nach dem 2. Wechsel hatte ich nen Server erwischt, der auf einmal problemlos lief.

xnor
24.05.09, 10:39
Hallo,

/etc/init.d/open-iscsi status zeigt eine Verbindung an.

Und übrigens: gestern Nachmittag ist es wieder passiert :-(. Auf dem zweiten Server (nicht bei OVH) wurde mitgelogt und dort war auch kein weiterer Eintrag zu finden.

Inzwischen bin ich ehrlich gesagt sehr kurz davor OVH zu verlassen. Nicht nur, dass meine RPS es nicht schaft mehr als 4 Tage uptime hinzubekommen. Das wäre schon schlimm genug. Sondern der Support braucht darüber hinnaus 2-4 Tage um mir immer mal wieder zu sagen, dass der Filer OK ist.

Liebe OVHler: ich bestreite ja nicht, dass der Filer OK ist. Aber irgendetwas ist nicht OK. Und wenn Ihr den Turnover in Griff bekommen wollt wäre das jetzt Eure Chance dazu.

Wie schon öfter meine unbeantworteten Fragen:
  • Erkennt Ihr, dass ein Problem vorliegt?
  • Kann ich etwas tun, um das Problem zu lösen?
  • Was tut Ihr um das Problem zu lösen?
  • Wann wird mein Server stabil laufen?


Immer noch auf Antworten wartend

Joern

piespy
22.05.09, 16:25
Zitat Zitat von xnor
genau das ist ja das was ich mir wünschen würde
Ja, ist klar. Damit das geht, muss soviel ich weiss der iscsid laufen und durch iscsiadm korrekt initialisiert worden sein, wie es normal durch /etc/init.d/open-iscsi geschieht.

Aber was genau schiefgelaufen ist wenn es nicht geht, dazu weiss ich leider nicht genug über iscsi. Und man kann es so wahnsinnig schlecht testen, weil die Filer zwar immer mal wieder, aber zu unregelmässig abstürzen...

Zeigt "/etc/init.d/open-iscsi status" denn eine Verbindung an und läuft iscsid tatsächlich?

xnor
22.05.09, 09:24
Zitat Zitat von piespy
...aber sobald der Filer wieder geantwortet hat, ging's einfach wieder weiter.
genau das ist ja das was ich mir wünschen würde

piespy
21.05.09, 18:32
Oh, dann war mein Problem vielleicht doch was anderes. Aber nichtsdestotrotz sollte das iscsi Programm auf 2.6.28+ angepasst werden.

Mit den früheren Kernels hatte ich nur kurz immer mal wieder eine Unterbrechung wenn der Filer ein Problem hatte oder ein Switch dazwischen abgeraucht ist oder so, aber sobald der Filer wieder geantwortet hat, ging's einfach wieder weiter.

xnor
21.05.09, 18:24
Allerdings: bei mir gab es auch mit 2.6.27 die Hänger, wenn ich mich nicht sehr täusche, der war nämlich am Anfang zum Booten voreingestellt.

piespy
21.05.09, 15:06
OK, mit 2.6.27 geht alles. Das GRSEC ist zwar etwas nervig, aber egal. Habe zum Test danach nochmal 2.6.28 probiert und er ist beim Boot wieder gehangen als iscsi geladen werden sollte.

Also an OVH die Bitte, den 2.6.27 Kernel zunächst in der Netboot Auswahl zu lassen bis auch die neueren Kernel mit iscsi gehen, und für diese muss dann vermutlich open-iscsi-2.0-871 oder höher zur Verfügung getstellt werden (ich habe selber aber nicht probiert, ob es damit wirklich geht).

piespy
21.05.09, 13:43
auf der open-iscsi Seite habe ich folgendes gelesen:
Code:
- The current testing/rc release: open-iscsi-2.0-871-test4.tar.gz   
(This adds support for 2.6.28 - 2.6.30, and adds support for Chelsio's cxgb3i iSCSI offload driver. See section 5 of the README for how to setup cxgb3i.)
Der aktuelle netboot Kernel ist eben 2.6.28, also kann es gut sein dass das aktuelle open-iscsi 2.0-870 von OVH damit Probleme hat. Kann ich einfach diese Version für mich kompilieren oder brauche ich da OVH-spezifische Anpassungen?

[edit] In der open-iscsi newsgroup ist ausserdem die Rede, dass 2.6.28 Kernels vor 2.6.28.7 einen Bug haben, der aber in 2.6.28.7 oder 2.6.29 behoben sein soll.

Ich habe schon mehrmals versucht, meinen eigenen Kernel zu starten aber bisher habe ich nur den netboot Kernel zum Laufen gekriegt. Da muss ich also warten bis OVH einen aktuellen Kernel anbietet. Vermutlich muss ausserdem auch noch der open-iscsi aktualisiert werden, bevor es zuverlässig tut. Jetzt werde ich es nochmal mit 2.6.27 probieren.

bene
20.05.09, 20:46
@xnor: Das sie dir nicht geantwortet haben "Have you tried to switch it off and on again?" grenzt ja schon an ein Wunder

Das kein Fehler am Filer vorliegt mag alles sein, dann gibt es ein Fehler woanders und diesen ignoriert gekonnt bzw denkt sich "ach die sind eh alle DAUs" scheinbar.

Naja wie gesagt, gibt ja zum glück mehr als einen Anbieter von Servern...

xnor
20.05.09, 15:05
Zitat Zitat von xnor
...es ist ja nicht so, dass ich das (nicht nur einmal) nicht getan hätte. Nur gab es dort bis jetzt noch keine Lösung. Jetzt schaut der Tech Support grade mal wieder nach dem iscsi-filer.
So, der Support hat geantwortet. Es gibt keinen Fehler am Filer. Und meine Logs enthalten auch keinen erkennbaren Fehler. Ticket geschlossen.

Ich habe es jetzt wieder aufgemacht. Eine Lösung ist das ja leider nicht.

Shaun
19.05.09, 21:08
Ich habe nach dem letzten "Hänger" auch mal den netboot Beta-Kernel gestartet. Bis jetzt hält er durch.
Allerdings scheint die iscsi Version die gleiche wie im Std. Kernel zu sein.

piespy
19.05.09, 17:11
Falls jemand zwei Server hat oder so, könnte man ja den syslogd auf den anderen Server mitloggen lassen, vielleicht gibt es dann eine sinnvolle Meldung.

Ich hab auch mal ein Ticket aufgemacht, aber bisher nur gehört dass es jemand zugewiesen wurde. Das Problem scheint zumindest bei mir der iscsi-adm Befehl zu sein, bis der aufgerufen wird funktioniert alles wunderbar, aber ich kann nur booten wenn ich den Befehl in the /etc/init.d/open-iscsi auskommentiere. Sonst hängt er bis ich ihn neu booten lasse.

Ich frage mich ja, ob das iscsi im neuen netboot-Kernel einfach nen Bug hat. Ich werde nachher mal den Beta-Kernel testen ob's damit besser läuft.

xnor
19.05.09, 10:24
Zitat Zitat von Stefan_
Kontaktiert den Kundendienst mit dem Problem, falls noch nicht passiert.
Gut, wenn noch entsprechende Logs mitgeliefert werden können.
...es ist ja nicht so, dass ich das (nicht nur einmal) nicht getan hätte. Nur gab es dort bis jetzt noch keine Lösung. Jetzt schaut der Tech Support grade mal wieder nach dem iscsi-filer.

und heute Nacht gabs mal wieder nen Hänger:
ay 19 03:50:02 allmers postfix/smtpd[5647]: lost connection after RCPT from unknown[189.29.132.10]
May 19 03:50:02 allmers postfix/smtpd[5647]: disconnect from unknown[189.29.132.10]
May 19 03:50:17 allmers kernel: IPv6 addrconf: prefix with wrong length 56
May 19 11:11:31 allmers kernel: imklog 3.18.6, log source = /proc/kmsg started.
May 19 11:11:31 allmers kernel: BIOS EBDA/lowmem at: 0009fc00/0009e800
May 19 11:11:31 allmers kernel: Initializing cgroup subsys cpuset

Ich fürchte es gibt keine sinnvollen Log-Einträge, weil ja dann, wenn es spannend wäre das Dateisystem zum Log schreiben weg ist und nicht wieder kommt.

Und wieder: Erkennt Ihr, dass es ein Problem gibt? Wie geht es wann weiter?

Grüße

Joern

Laubie
19.05.09, 09:56
Hmm...
mein Server lief jetzt Monate durch - ohne Probleme.
Vorgestern hab ich hier den Thread gelesen, und heute hängt mein Server auch...
Hätte ich m al blos nicht den Thread gelesen

Ich werde gleich - wenn der Server wieder da ist - mal nach den Logs schauen.

Gruß
Laubie

Edit:
habe mal geschaut.
letzer Eintrag im Syslog war
Code:
May 19 10:32:01 r21278 /USR/SBIN/CRON[29131]: (root) CMD (/usr/local/ispconfig/server/server.sh > /dev/null 2>> /var/log/ispconfig/cron.log)
May 19 10:32:01 r21278 /USR/SBIN/CRON[29132]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)

Stefan
18.05.09, 14:58
Kontaktiert den Kundendienst mit dem Problem, falls noch nicht passiert.
Gut, wenn noch entsprechende Logs mitgeliefert werden können.

Stefan

Shaun
18.05.09, 10:30
Heute Nacht ist mein RPS I schon wieder mit den gleichen Phänomenen stehen geblieben.
Ich finde es auch frech, dass OVH versucht das Thema auszusitzen.

as1x
18.05.09, 07:22
@ bene:
Mein RPS I ist auch auf dem iscsi64.
Ausser etwas größere Lags (1-2 Sekunden) tagsüber, läuft er ganz gut.

Der einzige Vorfall bis jetzt, war ein unerklärlicher Reboot vor 5 Tagen etwa. Es war nichts in den Logs zu finden, einfach Strom aus / Strom an.

piespy
18.05.09, 00:12
Mein Server ist jetzt seit über einem Jahr prima gelaufen. Aber heute hat er sich mal aufgehängt und liess sich danach auch nicht mehr starten. Im vKVM habe ich rausgefunden, dass er sich beim Booten jedesmal wieder neu aufhängt wenn er open-iscsi starten will.
Code:
Starting iSCSI initiator service iscsid0
Setting up iSCSI targets
Und da hängt er dann auf alle Ewigkeit. Ist das das gleiche Problem? Wurde kürzlich ein neuer Kernel in den Netboot gestellt (ich mache immer netboot), mit dem der iscsid nun nicht mehr kompatibel ist?

Was kann ich da machen? Der Rechner läuft jetzt wieder ohne (offensichtliches) Problem weil ich den open-iscsi aus dem startup rausgenommen habe. Aber der hatte da ja vermutlich schon eine Funktion...

chems
17.05.09, 21:26
Seitdem ich RPS-II habe geht das ja gott sei dank alles gut.

Mich verwunderte nur, dass dauerhaft Updates kommen, was OVH neues einführt, aber ein wirkliches krasses Problem scheinbar nicht so wichtig ist.

Ich hoffe für alle Kunden, die hier noch Probleme haben, dass es sich bald endlich mal löst, und OVH mal Wiedergutmachungen für die Kunden zahlt, die dauerhaft ihre Server am "sterben" sehen.

xnor
17.05.09, 18:36
Zitat Zitat von bene
Nichstdestotrotz ist es mir echt unverständlich, wie man ein Problem dass nun in dieser Häufigkeit hier genannt wurde einfach gekonnt igonieren kann.

Bin echt dahingehend echt enttäuscht, obwohl ich jahrelang zufriedener OVH Kunde war.
Ja, das ist auch mein Problem damit. Genau das, dass ich mich als betroffener relativ allein gelassen fühle.

Ich würde mir von OVH wünschen, dass man sagt, dass hier ein Problem existiert. Und ich würde gerne sehen, dass mit einer gewissen Priorität daran gearbeitet wird eine Lösung zu finden.

Liebe OVHler, seht Ihr das Problem?
Können wir betroffenen irgend etwas tun, um eine Lösung zu finden?
Wie geht es weiter?
Gibt es irgendeinen zeitlichen Horizont, wann abzusehen ist, dass es problemlos läuft?

Nur so Fragen...

Joern

bene
17.05.09, 17:31
@chems: Ja die Nutzung von "deutschen" RPS die Daten eh aus Roubaix holen hat sich mir auch noch nicht 100%ig erschlossen. Macht höchstens für Gameserver oder andere Applikationen sinn, die nahezu ausschließlich im RAM laufen...

Mein betreffender RPS ist unter einer franz. Referenz gehostet, und der Support dort ist auch gelinde gesagt unter aller Sau. Nach Tagen bekam ich als Antwort ein Link auf travaux.ovh.net geschickt der rein gar nichts mit meinem Problem zu tun hatte.

Der ovh.de Support ist wenigstens bemüht, kann aber eben leider auch nicht mehr machen als es als Ticket nach Frankreich abzukippen.

Da das Problem ja scheinbar nur die RPS-I betrifft, es schrieben schon mehrere dass nach einem Upgrade auf ein RPS-II keine Probleme mehr gab, kann evtl das Problem auch am Board bzw dem Atom liegen, dass dieser ab und zu mit andern sachen eben so beschäftigt ist, dass er die iSCSI verbindung sterben lässt...

Nichstdestotrotz ist es mir echt unverständlich, wie man ein Problem dass nun in dieser Häufigkeit hier genannt wurde einfach gekonnt igonieren kann.

Bin echt dahingehend echt enttäuscht, obwohl ich jahrelang zufriedener OVH Kunde war.

Shaun
17.05.09, 12:27
Ich reihe mich mal in die Gruppe der Problemserver mit ein.
Mein RPS I lief eigentlich zuverlässig (bis auf nicht funktionierendes IPv6). Aber in den letzten Tagen hing er schon 3 mal.
Die Probleme sind exakt die gleichen wie bereits von den Mitleidenden genannt:
Alles was Plattezugriff braucht geht nicht mehr: syslog, sysstat, ssh, etc., nur ping ist noch möglich.

Marian
17.05.09, 09:20
Mein RPS I läuft ebenfalls seit gut 40 Tagen ohne Probleme

marius
17.05.09, 09:05
Mein RPS II läuft ohne Probleme.
Weiter so!

chems
17.05.09, 03:43
Bene, ich kann deine Argumentation voll nachvollziehen. Auch ich hatte mit 2 RPS-I dauerhaft Probleme. Erst als ich auf einen komplett anderen RPS-II umgestiegen war, ging auf einmal alles. Mich verwundert es, dass das ISCSI so oft Probleme macht.

Ich erhielt dann wenig hilfreiche Nachrichten von Frankreich mit Inhalten wie "In den Logs ist nichts zu finden" - wo ich in allen Nachrichten vorher schrieb, dass ab dem Abbruch der Verbindung natürlich nix mehr in den Logs schrieb...

Was mich jedoch noch viel mehr verwundert hatte war die Idee, die Server in verschiedenen Ländern zu hosten, zum Beispiel Deutschland, und den Speicher in diesem komischen Valley zu lassen. Wenn ich das lese, so denke ich, dass es eher sinnvoll wäre, die Technik für alle Kunden stabil zum laufen zu bringen, ehe man das ganze noch über das Internet wagt. Und ich frage mich auch, wie performant ein solches System sein würde, wenn man Latenzen vom User zum Server hat, dann fragt der Server in Deutschland im sogenannten "Valley" nach seinen Daten, die dann zurückgehen, und dann wird dem User die Pakete geschickt.

Empfinde ich als sehr kritisch die Sache. Schöner wäre es da, ein eigenes deutsches Rechenzentrum zu haben, was unabhängig vom französischen Valley läuft. Schön wäre es deshalb, weil deutsche Techniker endlich die deutschen Nachrichten lesen könnten, und nicht das automatisierte System die Nachrichten in französisch übersetzt. Würde mich echt glücklicher machen, weil dann der gute deutsche Telephonsupport endlich mal direkt ein Problem an Techniker weiterreichen könnte, und nicht immer erst der nicht ganz so toll funktionierende Weg über das seltsame Valley gehen würde ^^

bene
16.05.09, 16:54
Hm, das problem mit den RPS scheint ja definitiv real zu sein, auch wenn OVH es irgendwie nicht sehen will sondern sich da bewusst blind stellt.

Meine Geduld ist schon lange am ende. Jeder 99ct billigst vServer läuft zuverläsiger als dieser Schrott hier...
Werd meinen RPS auch auslaufen lassen, spart einem viele nerven

xnor
16.05.09, 10:14
...und wieder:

May 16 04:40:12 allmers postfix/smtpd[2308]: lost connection after RCPT from unknown[81.27.108.62]
May 16 04:40:12 allmers postfix/smtpd[2308]: disconnect from unknown[81.27.108.62]
May 16 11:10:17 allmers kernel: imklog 3.18.6, log source = /proc/kmsg started.
May 16 11:10:17 allmers kernel: BIOS EBDA/lowmem at: 0009fc00/0009e800
May 16 11:10:17 allmers kernel: Initializing cgroup subsys cpuset

Langsam aber sicher ist meine Geduld am Ende. Ich würde mich sehr über eine Lösung freuen...

Grüße

joern

Jenstheclown
15.05.09, 15:32
Zitat Zitat von Christian R.
Der Speicherplatz ist am iscsi33, hat der zur Zeit irgendwelche Probleme? Oder muss es an mir liegen?
http://travaux.ovh.net/?PHPSESSID=5b...all&perpage=50

Filer33 hatte dieses Jahr noch kein problem vorzuweisen.

Christian R.
15.05.09, 15:09
Mein Server hing sich auch gestern auf.
Dann versuchte ich Hardware Reboot. Und jetzt geht garnichts mehr.
Seit ca 24 Stunden bekomme ich nun "Connection Refused" wenn ich SSH connecten will. Ping ist da.
Der Speicherplatz ist am iscsi33, hat der zur Zeit irgendwelche Probleme? Oder muss es an mir liegen?
Den Kundendienst habe ich gestern Abend informiert, bisher noch keine Antwort.

xnor
14.05.09, 18:45
so. Mit dem Update gabs auch einen Hänger. Allerdings konnte ich im Terminal diesmal zwei Logzeilen sehen, die es nicht mehr mit in die Datei geschafft haben, nach dem Hardreset waren sie weg:

May 14 19:30:51 allmers kernel: connection1:0: ping timeout of 5 secs
expired, last rx 25300706, last ping 25301956, now 25303206
May 14 19:30:51 allmers kernel: connection1:0: detected conn error (1011)

Sagt das wem was?

Danke und Grüße

Joern

xnor
13.05.09, 14:49
Zitat Zitat von kro
Wir haben mal einen rekompilierten iscsid bereitgestellt, wenn ihr es mal mit
dem probieren könntet
na denn schauen wir mal.
Gibt es eigentlich einen speziellen Grund, warum Ihr nicht den iscsid von Debian nehmnt?

J.

kro
13.05.09, 13:54
Wir haben mal einen rekompilierten iscsid bereitgestellt, wenn ihr es mal mit
dem probieren könntet - installation geht mit:

wget ftp://ftp.ovh.net/made-in-ovh/dedie/...pdate-iscsi.sh -O update-iscsi.sh && /bin/bash update-iscsi.sh
--
Felix
OVH Team

mpexx
13.05.09, 12:51
"Problem"-RPS II:
Code:
Linux ****.ovh.net 2.6.28.4-xxxx-std-ipv4-32 #2 SMP Wed Feb 18 16:34:04 UTC 2009 i686 GNU/Linux

iscsid version 2.0-870
Mein RPS I:

Code:
Linux ****.ovh.net 2.6.27.10-grsec-xxxx-grs-ipv4-64 #4 SMP Wed Feb 18 16:30:31 UTC 2009 x86_64 GNU/Linux

iscsid version 2.0-870

xnor
13.05.09, 12:33
# iscsid --version
iscsid version 2.0-870

# uname -a
Linux allmers.eu 2.6.28.4-xxxx-std-ipv6-32 #2 SMP Wed Feb 18 16:36:08 UTC 2009 i686 GNU/Linux

Kernel aus dem Netboot. Meine RPS hängt an iscsi22.rps.ovh.net und war heute schon zwei mal weg :-(

kro
13.05.09, 12:24
mpexx wrote:
> Auf beiden läuft Lenny. Das Problem tritt nur bei dem RPS II auf.


beide 32/64bit? kannst du mal die exakten kernelversionen der beiden posten?
(uname -a)
--
Felix
OVH Team

mpexx
13.05.09, 10:21
Die Version stimmt bei mir

Dazu muss ich noch folgendes sagen:

Ich habe einen "eigenen" RPS (RPS I) und verwalte einen RPS (RPS II) für unsere Firma.
Auf beiden läuft Lenny. Das Problem tritt nur bei dem RPS II auf.
Seltsam...

Edit:
Falls es am SAN liegen sollte. Der "Problem-RPS" hängt auf iscsi56.rps.ovh.net

kro
13.05.09, 10:08
xnor wrote:
> Und: das Netz bleibt ja bestehen, pingen geht ja, nur alles was ne
> "Platte" braucht ist tod


welche iscsid-Version ist bei dir installiert?

# iscsid --version
iscsid version 2.0-870
--
Felix
OVH Team

xnor
13.05.09, 07:51
...und heute morgen ist es wieder passiert.

Der Support hatte vorgeschlagen, OCO zu deaktivieren, aber das hat nicht geholfen.

igi
12.05.09, 16:56
Hatte das Problem auch hab darauf hin meinen Server mal mit NFS neu aufgesetzt und siehe da seit dem ist das "hängen" nicht mehr vorgekommen.

Ist eben auch nur ein Workaround das eigentliche Problem ist dadurch ja immer noch nicht gelöst

xnor
12.05.09, 16:43
Zitat Zitat von kro
Ich kann da absolut nichts fehlerhaftes erkennen.

Habt ihr denn irgendwelche Software installiert, die eventuell periodisch (oder auch nicht-periodisch) an netzwerk/routing/iptables/mountpoints oder ähnlichem drehen könnte, in etwa irgendwelche monitoring- oder sicherheitstools?

Wenn ja diese mal temporär deaktivieren um etwaige Fehler auszuschliessen.

Felix
Eigentlich keine spannenden Monitoring Tools, denke ich. Und: die Hänger kamen auch nicht genau zu Zeiten, wo etwa der Munin-Cronjob läuft.

Und: das Netz bleibt ja bestehen, pingen geht ja, nur alles was ne "Platte" braucht ist tod

Felix
12.05.09, 15:32
Zitat Zitat von xnor
Irgendwelche Ideen?
Ich kann da absolut nichts fehlerhaftes erkennen.

Habt ihr denn irgendwelche Software installiert, die eventuell periodisch (oder auch nicht-periodisch) an netzwerk/routing/iptables/mountpoints oder ähnlichem drehen könnte, in etwa irgendwelche monitoring- oder sicherheitstools?

Wenn ja diese mal temporär deaktivieren um etwaige Fehler auszuschliessen.

Felix

xnor
12.05.09, 13:54
gut, aber das kann ja keine Lösung sein :-(

Gut zu wissen, dass der Fehler nicht nur bei mir auftritt...

Liebe OVHler: ich bin an einer dauerhaften Lösung interessiert. Wenn es etwas gibt, was hilft, den Fehler zu finden, mache ich mit. Aber lasst uns den Fehler finden. So sind die RPSen nicht ganz so attraktiv.

chems
12.05.09, 13:50
Ich hatte das Problem auch, und der Support konnte mir trotz vielen Anrufen / Ticket-Aktualisierungen nicht weiterhelfen.

Erst, seitdem ich auf RPS-2 geupgraded habe, passiert dies gott sei dank nicht mehr.

xnor
12.05.09, 13:32
bei mir auch Lenny, nicht von der Vorversion geupdatet neu installiert.

Ich habe auch noch keine Abhängigkeit von Laufzeit, Load, Net-Io etc. gefunden. Passiert einfach ab und zu.

Alles in allem sehr unbefriedigend.

mpexx
12.05.09, 09:05
Ahh. Ich dachte schon ich sei der einzige dem das dauernd passiert.
Hatte dann mal nen CRON eingerichtet, der den Server alle 12 Std. neu startet, da ich dachte es ist evtl. ein Softwareproblem. Hat aber leider nicht viel gebracht.

Welche Distri setzt Du ein?
Bei mir läuft Deb. Lenny.

xnor
12.05.09, 08:35
Hallo,

seit einiger Zeit hängt meine RPS immer mal wieder und muss neu gestertet werden. Vielleicht kann das gesammelte Wissen hier weiterhelfen.

Einige male pro Woche ist der Server weg. Keine Logeinträge mehr, keine Services reagieren mehr. Ping ist noch möglich.
Nach Reset via Manager alles wieder OK.

Was schon probiert wurde:

-Booten im Rescue und CPU/Speichertest. War OK.

-Iscid läuft:
allmers:~/admin# ps auxw | grep iscsid
root 3428 0.0 0.0 1924 428 ? Ss 09:02
0:00 /sbin/iscsid
root 3429 0.0 0.4 2412 2408 ? S 0:00 /sbin/iscsid

-syslog (kein relevanter Eintrag vor und nach einem Ausfall)
Apr 29 06:57:51 allmers dkim-filter[3480]: 446331842F1 mode
select: verifying
Apr 29 06:57:51 allmers dkim-filter[3480]: 446331842F1: no
signature data
Apr 29 09:02:12 allmers kernel: imklog 3.18.6, log source =
/proc/kmsg started.
Apr 29 09:02:12 allmers kernel: BIOS EBDA/lowmem at:
0009fc00/0009e800
[und so oder so in etwa jedes mal]

-allmers:~# wget wget ftp://ftp.ovh.net/made-in-ovh/rps/open-iscsi
2009-04-29 13:49:03 (94,9 MB/s) - »open-iscsi« gespeichert [1748]
allmers:~# diff open-iscsi /etc/init.d/open-iscsi

sind auch identisch.


Irgendwelche Ideen? Leider ist der Support auch nicht wirklich hilfreich :-(...

Danke und Grüße

Joern