Neue Server schalten sich ab

[Rüdiger Kupper]

Der neue Server ltsp146 hat offenbar ein Problem, vielleicht Überhitzung? Bereits gestern abend hat er sich kurz nach dem Hochfahren einfach abgeschaltet. Beim zweiten mal hochfahren lief er weiter, heute morgen war er jedoch wieder aus.

Vielleicht ist ein Lüfter/Kühlkörper nicht richtig aufgesetzt.

Einstweilen habe ich den alten Server reaktiviert.

[Rüdiger Kupper]

Die Computerraumserver haben offenbar das gleiche Problem. Sie liefen so lange, bis Frau Strehlau mit ihren Schülern im Computerraum gearbeitet hat. Dann haben sie sich relativ gleichzeitig abgeschaltet.

Offenbar gehen die Rechner bei Last aus. Gründe könnten Überhitzung sein oder Überlastung des Netzteils.
Allerdings sind die Temperaturen im BIOS im normalen Bereich, und die Netzteile sind 350W-Teile.

Hast Du eine Idee?

[Rüdiger Kupper]

Ich habe die drei alten Computerraumserver wieder angestöpselt, sie stehen jetzt halt vor dem Schrank. USVs sind auch nicht dran.

An neuen Servern laufen jetzt noch:

• ltsp118
• ltsp126
• ltsp138

Bei allen anderen sind wieder die alten Server am Werk.

[Rüdiger Kupper]

Der neue ltsp146 steht übrigens gerade mit offenem Gehäuse da, falls Du einen Blick darauf werfen willst. Es gibt nur zwei Lüfter: Prozessor und Netzteil, beide drehen sich.

[bau]

Ich war gerade bei Dima-Computer und wollte ein größeres Netzteil, der meinte das könne man ausschließen.
Er tippt auf das Board (da Netzteil groß genug = er meinte da kommen maximal 260W zusammen, und Marken-Prozessor mit AMD-Lüfter und Marken Speicher (Kingston) bleibt das Board) - er empfiehlt neben dem Test der Temperatur mal ein BIOS-Update zu machen (das empfiehlt übrigens ASUS selbst auch, habe ich aber nicht gemacht).

[Rüdiger Kupper]

Interessant fände ich auch, ob die drei ersten Server stabil weiterlaufen. Wenn dem so ist haben wir einen Ansatzpunkt, um Unterschiede zu suchen.

Im Syslog ist übrigens rein gar nichts vermerkt. Die Rechner fahren nicht herunter, sondern werden einfach abgeschaltet. Das kenne ich eigentlich vor allem von überhitzenden Prozessoren. Bist Du sicher, dass die Kühlkörper überall richtig aufgesetzt sind und guten Kontakt haben? (Ich hab versucht, mal einen abzunehmen, wusste aber nicht wie. Locker war er jedenfalls nicht.)

[Rüdiger Kupper]

BIOS-Update schön und gut, aber eigentlich kann ich mir's nicht vorstellen, dass es daran liegen sollte.

Wie würde ein BIOS-Update denn bei denen ablaufen?

[Rüdiger Kupper]

Heute gleiches Spiel bei ltsp138: Habe den alten Server reaktiviert.
Jetzt laufen nur noch zwei neue Server: ltsp118 und ltsp126.

[bau]

Anscheinend wäre die Verwendung eines anderen Netzteils vorteilhaft. Ich werde nunn trotz der Aussage von Dima ein stärkeres Netzteil besorgen (eines mit 8PIN).
Auch wäre die BIOS-Einstellung surge protection = disabled wohl hilfreich.

​http://vip.asus.com/forum/view.aspx?id=20120109082055867&board_id=1&model=M5A88-V+EVO&page=1&SLanguage=en-us

[bau]

LTSP145 läuft nun mit einem 600W-Netzteil, mal sehen wie lange :-)

[Rüdiger Kupper]

Gut, hoffen wir das beste :-).

[bau]

Leider hat sich der LTSP146 auch mit 600W-Netzteil wieder abgeschaltet :-(

[bau]

auf LTSP145: BIOS-Update von Version 1001(30.12.2011) auf Version 1502 (21.8.2012) durchgeführt - mal sehen, ob der jetzt stabil läuft...

Der Hinweis auf das BIOS-Update stand übrigens auf rotem Papier (also wichtig) bei den Unterlagen zum Prozessor!

[Rüdiger Kupper]

Aha, dann war's vielleicht wirklich ein echter Bug.
Andere Frage: hattest Du vorher nicht auch eine geänderte BIOS-Einstellung ausprobiert? Wie war denn da das Ergebnis?

[bau]

Nein, ich habe zuerst mal das BIOS upgedatet, da ich den roten Zettel in der Prozessorschachtel gefunden habe.

[bau]

LTSP118 ist jetzt wieder am Netz:
BIOS-Update und Option Anti-Surgery-Protect: disabled

[bau]

Sowohl LTSP118 als auch 145 haben sich pünktlich mit dem Hochfahren der Clients abgeschaltet, langsam macht das keinen Spaß mehr.

[Rüdiger Kupper]

Mist.

[bau]

Supportanfrage an Mindfactory gesendet, Antwort:

Sie die Speicher für das Mainbord freigegeben ? Versuchen Sie mach die Speicher runter zu takten auf 1600. Machen den alle Rechner das gleiche Fehlerbild ?

OK, runtertakten wäre doch mal eine Option, ich mache das gleich mal beim LTSP118.

[bau]

LTSP118 läuft nun mit heruntergetaktetem Speicher (derzeit 1333MHz, 1600 wären zu probieren).
Ich habe daraufhin die Clients alle per Script vom paedML-Server aufgeweckt - und er läuft noch - mal sehen, ob das anhält. Ich selbst habe mir zu Hause ja auch einen FX4core mit ASUS M5A78M Board zugelegt und habe dort 1333'er Speicher - was stabil läuft, vielleicht ist es das ja wirklich?

[Rüdiger Kupper]

Abwarten. Ich kann's mir nicht vorstellen. Falsch getakteter Speicher müsste zu Speicherfehlern führen, also zu unerwarteten Programmabstürzen. Das ist aber überhaupt nicht, was wir beobachten. Was wir sehen ist ein plötzlicher Ausfall der Stromversorgung, oder eine Notabschaltung des Prozessors.

[bau]

Schade, um 7.24 Uhr hängt er mit einem LOAD von 0.32, die sensors-Werte waren vorher auch nicht auffällig. Ich habe das dem Mindfactory-Support gemailt.

[bau]

Da gibt es eine ganz komische Sache im BIOS:
Im HW-Monitor zeigt der direkt nach dem Starten eine CPU-Temperatur von 51°C an, nachdem ich gebootet habe sind es bei Sensors grade noch 36°C.
Ich habe mal im BIOS die Option zum Auto-Herunterfahren bei CPU-Überhitzung abgeschaltet, das scheint mir bei AMD-CPU, die sich dorch irgendwie selbst runtertakten, wenn sie zu heiß sind, unnötig.
Die Clients habe ich grade alle von Hand hochgefahren, mal sehen, wie das weitergeht.

[Rüdiger Kupper]

Replying to bau:

Ich habe mal im BIOS die Option zum Auto-Herunterfahren bei CPU-Überhitzung abgeschaltet, das scheint mir bei AMD-CPU, die sich dorch irgendwie selbst runtertakten, wenn sie zu heiß sind, unnötig.

Die Rechner sind ja auch gar nicht heruntergefahren (das hätte man ja im Syslog gelesen), sondern einfach ausgegangen (Syslog bricht einfach irgendwann ab, als nächstes liest man die Meldungen vom Wiederhochfahren).

[bau]

Nun, ich denke, dass im Fall einer Überhitzung das BIOS nicht lange den Rechner herunterfährt sondern ihn einfach mal abwürgt und das haben wir ja dauernd.

[bau]

Juhu, die Maschine läuft noch! Sie hat die 7.30 Uhr überstanden, ich glaube die blöde Anti-Überhitzungseinstellung war's wirklich gewesen!
Ich werde heute mittag die restlichen Server umstellen.

[bau]

Maschine läuft auch weiterhin :-)
Nun sind alle 7 LTSP-Server mit der neuen Hardware am laufen.
Auf allen habe ich das BIOS upgedated und die beiden Einstellungen auf diabled gesetzt,lm-sensors ist nun überall installiert. Ausßerdem habe ich die Uhr gegen den 10.32.1.253 mit ntpdate gestellt und mit hwclock -w in die Mainboraduhr geschrieben. Auf allen LTSP-Servern läuft nun auch ntp gegen den 10.32.1.253.

[bau]

Sch...
ltsp1 und 2 laufen noch, 3-7 sind offline :-(
Komisch, was ist an ltsp1 jetzt anders als an den anderen?
1 und 2 unterscheiden sich dadurch, dass an 2 keine Arbeitsstation hängt und somit auch wenig Browserspiele laufen. Deshalb lief 2 glaube ich bislang unproblematisch durch.

[bau]

Das Einzige, was ich an ltsp1 anders gemacht habe, als an ltsp3-7 ist, dass ich ein BIOS-Programm names OC Utility aufgerufen hatte, welches beim Overclocking behilflich sein soll. Alle mir sichtbaren Einstellungen habe ich anschließend wieder auf Auto gestellt. Das habe ich jetzt bei ltsp3 und 4 auch gemacht (eigentlich Schwachsinn, der Prozessor war in dieser Zeit mal kurz auf 3800MHz statt 3100). Ich weiß langsam nicht mehr, wo das hinführt!

[Rüdiger Kupper]

Replying to bau:

Auf allen LTSP-Servern läuft nun auch ntp gegen den 10.32.1.253.

hast Du das auch schon in die lts.conf geschrieben? Dort steht nämlich der paedml, d.h., die Clients fragen beim Hochfahren den paedml nach der Zeit. Jetzt sollen sie ja den 253er fragen.

[Rüdiger Kupper]

Fällt das Problem von #692 in die Zeit, wo die neuen Server im Computerraum liefen? (Hat Ruben heute um 9:12 erstellt). Dann können wir das getrost als Duplikat von diesem hier kennzeichnen. Wenn zu der Zeit schon wieder die alten Server dranhingen, ist es ein anderes Problem.

[bau]

Nein, das muss noch in die lts.conf hinein.
Ruben konnte zunächst garnicht mit den Rechnern arbeiten bis ich ihm die alten Rechner wieder hingestellt habe. Es laufen jetzt also die ltsp5-7 mit der alten Hardware, 1-4 mit der neuen.

[Rüdiger Kupper]

Frage nebenbei: Haben wir eigentlich mit den neuen Maschinen auch Support mitgekauft? Dann würde ich das Problem allmählich mal dem Support übergeben, mit dem Hinweis, dass wir die Sachen zurückgeben, wenn das Problem nicht schnell gelöst wird. Wir haben sicher beide keine große Lust, noch weiter Rätsel zu raten.

[Rüdiger Kupper]

Ich habe auf den verfügbaren neuen Servern (ltsp1-4) ​cpuburn installiert. Ergebnis: 30 Minuten cpuburn (100% Prozessorlast auf allen acht Cores) macht den Prozessoren überhaupt nichts aus:

• CPU-Temperatur 63-67°C (critical: 95°C) hoch, aber weit unter kritisch
• Power: 122-126W (critical: 125W) liegt im kritischen Bereich, doch keiner der rechner hat sich abgeschaltet

Schluss:

• CPU-Temperatur ist definitiv nicht unser Problem.
• Leistungsaufnahme ist bei Vollast durchaus kritisch (126W bei Vollast gegen 33W unbelastet), aber führt nicht zur Abschaltung
• der Grund für die Abschaltung ist unbekannt. Es ist jedenfalls nicht die Prozessortemperatur und nicht die elektrische Leistung!

Frage: Was führt dann eigentlich zur Abschaltung?

[Rüdiger Kupper]

Auch cpuburn auf allen Cores zusammen mit konstantem Festplattenzugriff (sudo find /) führt nicht zur Abschaltung. Ich frage mich, was es eigentlich ist, das den Rechner abschaltet?

[Rüdiger Kupper]

Ltsp4 ist z.B. mehrfach unmittelbar nach dem Hochfahren abgeschmiert (der Login Screen ist erschienen und im nächsten Moment war der Rechner aus). Was soll das denn eigentlich verursacht haben?

[bau]

Das ganze Problem scheint dubios, denn ich habe auf den Maschinen ja nichts weiter gemacht, als einen relativ schwachsinnigen Aufruf des Tools OC Tuner im BIOS, dessen Einstellungen ich eigentlich gleich wieder storniert habe. Ich werde aber, wenn die ltsp1-4 stabil weiterlaufen auf den Rechnern im PCRaum einen so bearbeiten und einen anderen daneben auf einem zweiten Monitor vergleichen, vielleicht finde ich im BIOS ja doch noch einen Unterschied.

Ich weiß nicht, ob man bei Mindfactory Support mitkauft. Sicher ist aber, dass wir ein Rückgaberecht für nicht funktionierende Hardware haben. Wenn die Kisten nicht stabil laufen, dann gehen die definitiv zurück.

[bau]

OK, das war's!
ltsp1 und ltsp4 sind wieder aus!
Ich schreibe gleich mal an den Support!
Eines habe ich aber noch im Internet gelesen: Anscheinend gibt es unter Ubuntu Schwierigkeiten mit dem Netzwerkkartentreiber - kannst du da mal danach sehen?

[Rüdiger Kupper]

ltsp3 ist heute Nachmittag wieder ausgefallen. Da läuft jetzt wieder der alte Server.

[bau]

Schön, das ist wenigstens konsistent, der einzige Server, der aktuell ohne Hänger durchläuft läuft an einem anderen Switch, alle anderen hängen an Cisco-Switchen. Die Seite habe ich nun auch wieder gefunden:

​https://bugs.launchpad.net/ubuntu/+source/linux/+bug/896575

unsere LTSP laden den rtl8169-Treiber, erkennen aber die Netzwerkkarte als rtl8111/8168B:

root@ltsp126:/localhome/linadmin# lshw -class network
  *-network               
       Beschreibung: Ethernet interface
       Produkt: RTL8111/8168B PCI Express Gigabit Ethernet controller
       Hersteller: Realtek Semiconductor Co., Ltd.
       Physische ID: 0
       Bus-Informationen: pci@0000:06:00.0
       Logischer Name: eth0
       Version: 06
       Seriennummer: c8:60:00:60:b3:63
       Größe: 1Gbit/s
       Kapazität: 1Gbit/s
       Breite: 64 bits
       Uhr: 33MHz
       Fähigkeiten: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       Konfiguration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=10.32.1.249 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       Ressourcen: irq:52 ioport:e800(Größe=256) memory:fdfff000-fdffffff memory:fdff8000-fdffbfff

lsmod: [...]
r8169                  62099  0 

[bau]

Das kann aber auch nicht das Thema sein, denn auf den alten Boards ist auch der 8111/8169B verbaut!

[bau]

Obwohl: siehe #692:
​http://unixblogger.wordpress.com/2011/10/18/the-pain-of-an-realtek-rtl8111rtl8168-ethernet-card/
scheint doch interessant zu sein!

[bau]

Auf dem paedml existiert das Problem jedenfalls nicht, dort sind zwei NVidia-NIC verbaut!

Ich habe nun zum Test an den LTSP2 die Arbeitsstation 1 und 2 angehängt (hingen bislang an LTSP1) - mal sehen, ob der heute überlebt!

[Rüdiger Kupper]

Ich kann mich (Mi, 22:00 Uhr) auf dem ltsp2 nicht mehr einloggen: connecton closed by remote host. Das heißt, der Rechner läuft zwar noch, aber er ist in einem Zustand, in dem zumindest der ssh-Server nicht läuft. -- Ist das das Ergbnis der Belastung durch die Arbeitsstationen?

[bau]

Mir sagt er: "no route to host" - ich habe es gestern leider vor lauter Hektik nicht geschafft den Server kontinuierlich zu überwachen - ich denke aber, der Zusammenhang ist eindeutig: Die Kiste läuft drei Wochen durch und sobald wir eine Arbeitsstation dranhängen und die Schüler ein wenig Online-Spielchen machen geht er aus. Anescheinend wurde er von den Kollegen in diesem U recht wenig beansprucht!

[bau]

Als LTServer128c läuft nun der neue mit r8168-Treiber - mal sehen, ob der den Tag morgen überlebt.
Die alten Server habe ich auf das Rack gestellt (längere Netzwerkkabel waren nötig). So kann ich morgen im Ernstfall bequem wieder umstellen.

Auf dem LTServer128b (alt) habe ich auch den r8168-Treiber installiert, auf LTServer128a läuft noch der r8169 - mal sehen, ob man da Unterschiede merkt.

[bau]

Ist-Stands-Meldung an mindfactory gesendet:

1. Wir haben das Kernel-Modul für die Netzwerkkarte Realtek 8111/8168 installiert

da gab es einen Linux-Bug, dass der Treiber für die 8111/8169 verwendet wurde und dadurch
das Netzwerk zusammenbrechen kann.

Ergebnis: der Test-Rechner hängt sich wieder auf, die alten Vergleichsrechner haben aber mit dem
neuen Treiber keine Probleme, ob es Vorteile im Netzwerk bringt ist uns derzeit noch nicht klar

2. Wir haben die 16GB HyperX per MemTest durchgecheckt - keine Fehler

3. Dabei ist uns aufgefallen, dass das Board die HyperX nur mit 1333MHz fährt (Einstellung: Auto)

4. Stelle ich die Taktung von Hand auf 1866MHz kann ich ins BIOS und auch den Memtest problemlos

ausführen, will ich aber den Linux-Kernel booten, so schaltet sich die Kiste aus

5. Komisch: Im Begleitblatt des HyperX-Speichers steht, dass er mit 1,5V angefahren werden soll,

auf den Speichermodulen habe ich aber einen Kleber gefunden mit: 1,65V ????
Das BIOS spricht die Module in der Einstellung AUTO mit 1,5V an

Es steht noch der Test aus, ob die Speicher mit 1,65V stabil laufen würden / überhaupt mit 1866MHz
laufen (die Taktung des AMD FX 8120 ist laut Beschreibung bevorzugt 1866MHz-Speichertaktung)

6. Ich habe nun bei Ihnen am Wochenende den im Verzeichnis QVL des Boards ausdrücklich

getesteten und zugelassenen Kingston ValueRam

8268121 4GB Kingston ValueRAM DDR3-1333 DIMM CL9 Single

bestellt - damit wollen wir die Boards noch testen

7. Die Speicher (HyperX 4x4GB) habe ich nun in einen der alten Server (ASUS M4A78 mit AMD Phenom II X4)

eingebaut wo sie anscheinend problemlos laufen.

[bau]

Punkt 5 ist nun auch getestet:
Das Board bootete einmal mit den Einstellungen 1866 und 1,65V, ich konnte dkms und das 8168-Kernelmodul laden. Beim Reboot hat er sich dann aber abgeschaltet und anschließend konnte ich ihn nicht mehr Reaktivieren - komische Sache - anscheinend liegt es wirklich am Speicher???

[bau]

Auf allen aktuell laufenden LTSP ist nun das r8168-Kernelmodul geladen.
ltsp5 und 6 laufen jetzt jeweils mit 8GB ValueRAM
ltsp7 ist NEU (M5A88 mit FX-8core und 16GB Kingston ValueRAM) - läuft derzeit ganz gut, morgen hoffentlich auch noch!
ltsp1-4 sind ASUS M4A78-EM-Boards, die vertragen nur DDR2-Speicher, haben jeweils zum Board passenden HyperX 2x2GB drauf (Bei Gelegenheit werde ich aufrüsten). Es ist 2x eine Phenom XII und zweimal ein Athlon XII verbaut. Gelegentlich werde ich ein BIOS-Update machen, dann können wir mal mit dem ASUS-Core-Unlocker schauen, ob wir aus den zwei Phenoms nicht X4-Prozessoren machen können.

[bau]

Leider liegt es nicht am Speicher, der LTSP128c ist wieder aus, nachdem Schüler sich angemeldet haben.
Ich schicke nun ein Päckchen zu mindfactory

[bau]

Päckchen geht schnellstmöglich an mindfactory, habe es heute mit 4x Speicher, 1x Board, 1xProzessor+Lüfter gepackt. Ich habe ltsp5,6 und 7 mit jeweils 16GB Ram ausgestattet. Beim lokalen Hardwarehändler habe ich ein Gigabyte-Board mit AMD 970-Chipsatz erworben und in den neuen ltsp7 eingebaut. Leider hat der Chipsatz keine Onboard-Grafikkarte, da habe ich eine PCIExpress-Karte aus dem Fundus genommen. Leider schaltet Ubuntu/der Kernel die Netzwerkkarte ab, weshalb der Boot ewig dauert (kein NFS-Mount möglich). Hast du eine Ahnung, was der Kernel haben könnte (es ist wieder eine RTL8111/8168!)?

[bau]

Mindfactory besteht nun auf einem Test der Boards mit Speicher von G.Skill. Die würden uns den Speicher austauschen (klar, wenn im Begleitzblatt 1,5V steht und auf den Speichern selbst 1,65V). Die Boards wollen sie nicht so recht tauschen, ich denke aber, da kommen die nicht drum rum. Also gur: sobald der Speicher da ist verbaue ich ihn und dann geht's halt in den Test mit ltsp7, wenn's nicht tut muss ich ja nur das Netzwerkkabel umstöpseln.

[bau]

So, nachdem der Test mit G.Skill Speichern absolut schief ging hat mindfactory nun ein einsehen gehabt und uns ein ASUS M5A97-EVO zugesandt. Schickes Board, neuestes Bios. Allerdings gibt es da keine onboard-Grafk mehr deahlb ist eine Radeon-GK mitbestellt. Läuft gerade als LTSP6 ich hoffe es hält durch. Angenehm: unser Kingston-Speicher steht ausdrücklich in der QVL dieses Boards!

[Rüdiger Kupper]

Ah, sehr gut, ich bin ehrlich gespannt!

[bau]

Nach einem Tag Test läuft er immernoch, das lässt hoffen :-)

[Rüdiger Kupper]

Fein!

[Rüdiger Kupper]

Wie ist denn der Zustand mit den neuen Servern? Der ltsp6 läuft ja seit Wochen vorbildlich.

[bau]

ltsp6 läuft seit 15 Tagen stabil - Problem gelöst.
Ich habe eine eMail an mindfactory wegen des weiteren Verfahren gesendet.

[bau]

Hardware ist im Haus, ich besorge noch Wärmeleitpaste und dann geht's los.
Wenn die Server alle zusammengeschraubt sind werde ich sie austauschen, dann kann R. Kupper die Updates auf den Kisten nachholen.

[Rüdiger Kupper]

Klingt gut, bin gespannt!

[Rüdiger Kupper]

Vorschlag für das Nachholen der Updates/Änderungen auf den Maschinen, die nun für einige Wochen nicht am Netz waren:

• Wenn ich die Sache richtig überschaue, hat ltsp6 bereits die neue Hardware und bleibt so wie er jetzt ist am Netz.
• Wenn Du die anderen Server zusammengeschraubt hast, gibt es zwei Möglichkeiten:
  1. Wir nehmen sie direkt ans Netz. Sie laufen dann mit der Software in dem Zustand, in dem sie außer Betrieb genommen wurden. Ich kopiere im laufenden Zustand das aktuelle System von ltsp6 auf alle anderen Server. Danach sollten alle auf dem gleichen Stand sein.
  2. Wir lassen die alten Server erst noch am Netz, und ich aktualisiere das System nach und nach auf jedem Server. Danach nehmen wir alle gemeinsam ans Netz.

1. Hat den Vorteil, dass ich es auf allen Servern gleichzeitig per cluster-ssh machen kann, z.B. über Nacht.
2. Ist die sicherere Methode, weil der Server erst ans Netz geht, wenn das System garantiert aktuell ist. Ich muss dazu aber mit meinem USB-Stick jeden einzelnen Server booten und das System rüberziehen.

[bau]

OK, ich würde vorschlagen, dass ich den LTSP4 als erstes ans Netz hänge (der alte tut ja eh nicht mehr) und die anderen einfach neben die alten stelle. Dann kannst du den ltsp4 vorab schonmal aktualisieren und die anderen dann, wenn du dazukommst.

[bau]

Erledigt: ltsp1,2,3,4,6 und 7 stehen nun an Ort und Stelle
Bei allen habe ich schonmal probeweise gebootet und die /etc/udev/rules.d/70-persistant-net gelöscht, bei ltsp7 (LTSP128C) war das ein wenig komisch, das war glaube ich der, an dem wir auch mit dem GigabyteBoard getestet hatten, ich denke, den musst du auf jeden Fall neu aufsetzen.

[Rüdiger Kupper]

Super! Sobald ich etwas Zeit hab, setze ich mich dran.

[Rüdiger Kupper]

• ltsp4 hat wieder ein aktuelles System (Kopie von ltsp6), hat sich aber zwischenzeitlich wieder verabschiedet (siehe #780)
• ltsp7 erhält gerade ein aktuelles System (Kopie von ltsp6)
• ltsp5 lässt sich leider nicht einschalten -- Einschaltknopf funktioniert nicht. Bitte bei Gelegenheit danach schaun.

[Rüdiger Kupper]

Replying to bau:

Bei allen habe ich schonmal probeweise gebootet und die /etc/udev/rules.d/70-persistant-net gelöscht, bei ltsp7 (LTSP128C) war das ein wenig komisch, das war glaube ich der, an dem wir auch mit dem GigabyteBoard getestet hatten, ich denke, den musst du auf jeden Fall neu aufsetzen.

An ltsp7 ist folgendes komisch: Er erkennt seine Netzwerkkarte hartnäckig als "eth1". Auch wenn man die persistant-net-Datei gelöscht hat, dann wird sie neu angelegt, aber mit dem Namen "eth1".

-> kann es sein, dass die Netzwerkkarte auf dem Mainboard irgendwie falsch angeschlossen oder gejumpert ist? Oder kann man im BIOS irgendwas konfigurieren? Das Ding hat doch nur eine Karte, oder??

Ich habe versucht, in die persistant-net-Datei einfach eth0 reinzuschreiben. Dann kann man sich wenigstens per ssh einloggen. Die Clients booten aber trotzdem nicht.

Fazit: ich hab jetzt knapp vier Stunden Arbeit reingesteckt und es läuft trotzdem nur ltsp6. ltsp5 und 7 sind jetzt wieder die alten Maschinen.

[bau]

ltsp7 ist derzeit garnicht am Netz?
Auf den Boards kann man definitiv nichts jumpern.
Entweder das tut oder wir tauschen es aus!

[Rüdiger Kupper]

Als ltsp7 hab ich gestern die alte Maschine wieder angeklemmt und einen Client davon gebootet. Warum der jetzt nicht mehr läuft, weiß ich nicht ...?

[Rüdiger Kupper]

Replying to bau:

Auf den Boards kann man definitiv nichts jumpern.

Würde ich heute auch nicht mehr wirklich erwarten. Aber vielleicht zwei Anschlüsse zur Auswahl, oder sowas? Aber vermutlich ist der Netzwerkport direkt auf die Platine gelötet...

[Rüdiger Kupper]

Die Ubuntu-Dokumentation (​https://help.ubuntu.com/12.04/serverguide/network-configuration.html) sagt ganz klar:

Interface logical names are configured in the file /etc/udev/rules.d/70-persistent-net.rules. If you would like control which interface receives a particular logical name, find the line matching the interfaces physical MAC address and modify the value of NAME=ethX to the desired logical name. Reboot the system to commit your changes.

Das habe ich getan. Danach fuhr der Rechner ohne Verzögerung hoch und ich konnte mich per ssh darauf einloggen. Die Clients haben aber nicht gebootet.

Außerdem ist völlig unklar, wieso das Netzwerk-Interface als eth1 erkannt wird. ltsp7 hat wieder das exakt gleiche System wie ltsp6...

[Rüdiger Kupper]

Aus einem Forum:

"ifconfig -a" will show all interface cards even if they are down.

Aha, das kann ich ja mal probieren, vielleicht erfahre ich dann, was "eth0" sein soll. Denn das Betriebssystem wird ja wohl kaum bei 1 anfangen zu zählen. Oder doch?

[Rüdiger Kupper]

Replying to bau:

ltsp7 ist derzeit garnicht am Netz?

Autsch! Ich hab gestern nochmal das Netzwerkkabel abgezogen und dann an den falschen Rechner zurückgesteckt.
=> wir hatten seit gestern abend zweimal den ltsp6 am Netz (alte UND neue Maschine).
interessanterweise scheint das keine Probleme gemacht zu haben. Ich nehme an, der Switch hat sich für einen der Rechner entschieden und den andern Zweig abgeschaltet. (Sind die so klug?)

[Rüdiger Kupper]

Jetzt sind alle sieben neuen Server wieder im Einsatz.
Wir werden also am Montag recht bald sehen, bei welchen die CPUs vielleicht einen Knacks haben.
Aber vielleicht laufen sie ja auch einfach mal...

[Rüdiger Kupper]

Mo, 8:42, bisher haben alle Server die 1. Stunde überlebt. Und wie ich sehe sind im Computerraum gerade 14+12+13 Schüler eingeloggt. Load auf den Rechnern ist unter 3.

[administrator]

Ich habe die LTSP-Server in die Konfiguration des Nagios3-Systems eingetragen, die werden jetzt regelmäßig auf host_alive getestet. Ebenso die ProxMox-Server (proxmoxl, proxmoxs, proxmoxtgs und proxmoxkwrs). Im Fail-Fall wird eine Mail an den Administrator gesendet.

[Rüdiger Kupper]

Genau sowas hatte ich auch vor, Gedankenübertragung...

Ich hab mir heute morgen mal das "Landscape" von Canonical angeschaut, das ist die Software, dei Canonical zur Verwaltung eines Netzwerks aus Ubuntu-Rechnern anbietet. Sieht ganz hübsch aus, ist aber zu teuer. Nach dem, was ich gelesen hab, wollen die mehr als 100€ pro verwaltetem Rechner.

Aber vielleicht gibt's kostenfreie Alternativen. Das Cluster-LTSP steht ja auch noch zum Test aus.

[Rüdiger Kupper]

Der Server-Ausfall heute Nachmittag hat im Syslog wieder keine Spuren hinterlassen. Der letzte Eintrag ist von 13:17, um 13:27 hab ich den Server neu gebootet:

Dec 10 13:17:01 LTServer128b KEPLER_MOUNTALL_WORKAROUND: Executing 'mount -a' in case NFS dirs are not mounted.
Dec 10 13:17:30 LTServer128b smartd[1873]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 63 to 62
Dec 10 13:27:01 LTServer128b kernel: imklog 5.8.6, log source = /proc/kmsg started.
Dec 10 13:27:01 LTServer128b rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="1311" x-info="http://www.rsyslog.com"] start
}

[Rüdiger Kupper]

Von Nagios kam übrigens keine Mail. Wie oft prüft das nach, ob der Server noch läuft?

[administrator]

Ich denke, die Einstellung 24x7 bedeutet, dass der jede Stunde einmal versucht den Rechner zu erreichen.

[bau]

LTSP4 ist nun wieder der alte (der der Probleme gemacht hat) nur eben mit NEUER CPU. Mal sehen, wie lange der es macht!

[Rüdiger Kupper]

Ltsp4 läuft nun seit sechs Tagen durch, ltsp6 seit 7 Tagen, alle anderen seit 10 Tagen.
Ich wage ja kaum, das Ticket zu schließen :-).

[bau]

Hattest du einen Riecher?
Kurz bevor ich vorher gegangen bin hatte mich Herr Krauß noch gefragt wegen der Dokumentenkameras. Vor Ort hatte der Client keine Verbindung mehr zum Server, dieser hing mit den bekannten Symptomen. Ich habe ihn einfach neu gestartet. Mal sehen, wie das weitergeht.
Als nächstes könnten wir mal einen AMD Phenom X6 ausprobieren, das hat bei mir zu Hause geholfen (mit meinem FX-4core hatte ich Kernel-Hänger ohne Zusammenhang). Kann eigentlich der Kernel Schuld sein?

[Rüdiger Kupper]

Och nö... :-(

Kern, hm, ich kann ja nochmal googeln, ob jemand ein vergleichbares Problem hat. Aber wonach genau suche ich denn nun? Glauben wir noch, dass es mit dem Prozessor zusammenhängt, oder ist die Frage wieder offen?

[Rüdiger Kupper]

Es fällt ja schon auf, dass es ltsp4 öfter zu treffen scheint.

[Rüdiger Kupper]

Nach Bericht von ros muss der Serverabsturz um 12:20 gewesen sein. Das passt zum Syslog, der letzte Eintrag dort stammt von 12:17. Leider enthält das Syslog wie immer keinen Hinweis, was zum Absturz geführt hat.

[Rüdiger Kupper]

ros berichtet übrigens, dass er verstärkt gegen 12:20 Unregelmäßigkeiten beobachtet. Mir ist dazu in Syslog des paedml folgendes aufgefallen: Regelmäßig immer gegen :20 und :50 bekommen wir Warnungen wegen der Festplattentemperatur. Welcher Prozess läuft denn da alle halbe Stunde?

root@paedml:~# less /var/log/syslog | grep "Celsius"
Dec 18 04:22:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 142 to 145 
Dec 18 04:22:08 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 
Dec 18 04:22:09 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 169 to 172 
Dec 18 04:22:09 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 166 to 169 
Dec 18 04:52:09 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 148 
Dec 18 05:22:10 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 
Dec 18 05:22:10 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 169 to 166 
Dec 18 05:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 145 to 148 
Dec 18 05:52:08 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 154 
Dec 18 06:22:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 
Dec 18 06:22:09 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 172 to 175 
Dec 18 06:22:09 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 166 to 169 
Dec 18 07:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 148 
Dec 18 07:52:09 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 175 to 172 
Dec 18 08:22:09 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 169 to 166 
Dec 18 08:52:09 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 166 to 169 
Dec 18 09:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 145 
Dec 18 09:52:09 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 154 to 151 
Dec 18 09:52:09 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 169 to 166 
Dec 18 10:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 145 to 148 
Dec 18 11:22:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 
Dec 18 11:22:08 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 154 
Dec 18 11:22:08 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 172 to 175 
Dec 18 11:22:08 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 166 to 169 
Dec 18 11:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 148 
Dec 18 12:22:09 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 
Dec 18 12:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 148 
Dec 18 13:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 145 
Dec 18 13:52:09 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 154 to 151 
Dec 18 13:52:09 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 175 to 172 
Dec 18 14:22:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 145 to 148 
Dec 18 14:22:08 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 154 
Dec 18 14:22:08 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 172 to 175 
Dec 18 14:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 
Dec 18 15:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 148 
Dec 18 15:52:09 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 154 to 151 
Dec 18 15:52:09 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 175 to 172 
Dec 18 15:52:10 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 169 to 166 
Dec 18 16:22:09 paedml smartd[31100]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 151 to 154 
Dec 18 16:22:09 paedml smartd[31100]: Device: /dev/sdc, SMART Usage Attribute: 194 Temperature_Celsius changed from 172 to 175 
Dec 18 16:22:09 paedml smartd[31100]: Device: /dev/sdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 166 to 169 
Dec 18 16:52:08 paedml smartd[31100]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 148 to 151 

Die Werte sind übrigens erschreckend hoch, 150°C ist viel zu heiß für Festplatten!

[bau]

Welche Prozesse da laufen weiß ich nun auch nicht.
Der Serverraum ist auf 20°C abgekühlt, der Server hat Gehäuselüfter nur keine Festplattenlüfter, die bekommt erst der neue Server. Kann das stimmen mit 150°C, das kommt mir recht hoch vor!

[Rüdiger Kupper]

Kann ich auch kaum glauben. Die SMART-Werte werden in Einheiten angegeben, die die Hersteller festlegen, es können also auch andere Einheiten als Celsiusgrade sein. Allerdings lautet die Warnung "Temperature_Celsius changed".

Wenn wir die Warnung erhalten, bedeutet das aber auf alle Fälle, dass die Temperatur über dem Grenzwert lag, den der Hersteller festgelegt hat.

[bau]

Ich habe gerade mal an die Festplatten hingefasst: Die sind derzeit alle gut gekühlt, noch nicht mal handwarm. Vielleicht wird im laufenden Betrieb bei größerer Belastung die Temperatur größer?

[Rüdiger Kupper]

ltsp4 war heute wieder aus. Hast Du an dem nochmal etwas verändert?

[bau]

Nein, Mist was haben die Dinger eigentlich!

[bau]

Die Festplattenwerte sind übrigens anscheinend problemlos, es werden komischerweise irgendwelche Anpassungen ausgegeben und nicht der tatsächliche RAW-Wert der Platte in °C. Der Befehl

smartctl -d ata -a /dev/sda | grep Temperature

gibt ganz hinten den Wert in °C an (der andere liegt grade bei 157 das entspricht 27°C).
Komische Sache, das!

[Rüdiger Kupper]

Ja, wie diese Werte normiert werden, ist ziemlich seltsam. Die meisten Hersteller scheinen die RAW-Werte auf das Intervall [0, 100] abzubilden, wobei 100 bedeutet ganz in ordnung und 0 defekt.

Bei der Festplatte, die ich mir neulich gekauft habe, scheint das Intervall aber [0, 200] zu sein. Das ist hier vermutlich auch so, also liegt 157 im Normalbereich.

Ist aber eine wirre Sache, die dauernd für Missverständnisse sorgt.

[Rüdiger Kupper]

Replying to bau:

Nein, Mist was haben die Dinger eigentlich!

Aber in ltsp4 war doch nun der neue Prozessor drin, und er ist trotzdem zweimal ausgefallen. In den Ferien ist er brav durchgelaufen, es passiert also nur unter Last.

Ich bin ziemlich ratlos. Warum trifft es vorwiegend ltsp4? Der versorgt zwar mehr Rechner als die anderen U-Server, aber noch viel eher müssten doch die Computerraumserver belastet werden?

[Rüdiger Kupper]

Hm, ltsp5 war auch aus, entnehme ich den Nagios-Meldungen? Hast du den wieder gestartet?
Interessanterweise zeigen die Nagios-Meldungen, dass ltsp4 und ltsp5 zu ähnlicher Zeit ausgefallen sind (gestern in der Stunde zwischen 12:45 und 13:45).

Ich verstehe, dass sich zu der Zeit vielleicht viele Schüler im Computerraum eingeloggt haben. Aber warum auch ltsp4?

[bau]

ltsp5 war nicht aus - das war leider eine Fehlkonfiguration (ich hatte bei beiden die gleiche IP eingetragn - zuviel Copy&Paste ist ungesund)

ltsp4 hat als einziger ein 600W-Netzteil drin, vielleicht ist da mit der Spannungsversorgung was problematisch? Ich wollte grade die aktuelle Leistung der USV auslesen:

  /etc/init.d/apcupsd status

leider ist das nicht installiert - ich kann es auch nicht installieren, da irgendein Update grade durchläuft. Kannst du das bitte auf allen ltsp installieren (in irgendeiner Datei muss man dann den Starter noch auf YES stellen, dann tut's schon) - DANKE

[Rüdiger Kupper]

Ltsp4 ist heute Mittag wieder ausgefallen, jetzt läuft er ohne USV.

[Rüdiger Kupper]

Ltsp2 war heute Nachmittag aus. Die erste Warnmail kam um 17:39.
Aber: Er ließ sich durch Druck auf den Einschaltknopf wieder einschalten. Daher vermute ich fast, ein Kollege hat ihn versehentlich ausgeschaltet. Mal sehn, was das Log hergibt.

[Rüdiger Kupper]

Hm? Er sagt "connection refused". Ich hab ihn aber vorhin neu angeschaltet, und es kam eine Recovery-Meldung von Nagios. Wieso kann ich dann kein ssh machen?
(Ah, Moment, die anderen Rechner hingen auch einmalig beim Reboot, ich weiß nicht warum, vielleicht ein kürzliches Update, das das verursacht. Nach nochmaligem Runter- und Hochfahren ging's dann jeweils wieder. Also müssen wir ltsp2 morgen früh vermutlich einmal aus- und wieder einschalten.)

[Rüdiger Kupper]

ltsp6 war eben aus, das bekannte Phänomen. Wie wär's, wenn wir einfach mal überall die USVs abhängen?

[bau]

Und schon wieder aus :-(
Hattest du die USV abgehängt?

[bau]

Ich bin grade vor Ort: USV war noch dran - habe diese vor dem Einschalten nun abgehängt.
Komisch, dass ltsp5 und 7 keine Probleme machen aber der 6'er hängt zuverlässig.

[Rüdiger Kupper]

Wie gesagt, vielleicht klemmen wir die USV einfach mal überall ab, dann sehen wir am schnellsten, ob die verantwortlich sind.

Komisch, dass ltsp5 und 7 keine Probleme machen aber der 6'er hängt zuverlässig.

Ist mir auch schleierhaft.

[bau]

Ja Pustekuchen :-(
ltsp6 ist auch ohne USV wieder mal offline. Ich werde jetzt mal die gerade getauschte CPU aufstecken - vielleicht hat die ja doch einen abgekriegt.

[Rüdiger Kupper]

Schade, schade, schade... Wieder eine Idee weniger.
Aber es fällt auf, dass es derzeit nur ltsp6 trifft. Warum?

[bau]

OK, neue Theorie: Der ltsp4 und der ltsp6 waren von Anfang an die Kummerkisten. Ich schätze mal, dass der Prozessor einen Defekt abbekommen hat (Speicher mit 1,65V anstelle von 1,5V. Zu Beginn liefen die Kisten ja alle ganz ordentlich, dann fiel immer wieder ltsp4 und ltsp6 aus, an den beiden haben wir am meisten rumexperimentiert. ltsp4 lief erst dann einigermaßen stabil, als ich ihm einen neuen Prozessor verpasst habe, der alte ist aus der Rekla zurückgekommen - den habe ich grade in ltsp6 eingebaut. Der hängt jetzt wieder wie seine Kollegen ltsp5 und ltsp7 an der USV im Schrank. Mal sehen, wie lange er durchhält.

[bau]

Ah ja, dabei habe ich mal die ganzen Kabel im Schrank mit Etiketten versehen und die Kabelwege neu gesteuert - es sieht nun deutlich ordentlicher im Schrank aus, das führt auch zu weniger Verwirrung :-)

[Rüdiger Kupper]

Gut! Ich hab mich außerdem gefragt, welches welcher Rechner ist. Die Beschriftung ist jetzt nämlich nicht mehr lesbar. LTServer128b ist der mittlere, aber welcher ist oben und unten?

[bau]

OK, das war's irgendwie auch nicht: ltsp6 ist trotz neuer CPU aus. Ich habe ihn mal ohne USV drangehängt. Wobei ich mir wenig Erfolg davon verspreche. Eventuell mal noch ein anderes Netzteil?

OBEN: ltsp5 (a)
MITTE: ltsp6 (b)
UNTEN: ltsp7 (c)

Auf dem Umschalter sind sie der Reihe nach: 1=a 2=b und 3=c (4 ist frei)

[Rüdiger Kupper]

Ts, heute morgen hab ich den ltsp6 neu gestartet (bei mir wollte er ;-) ), aber jetzt ist er bereits wieder aus!

[Rüdiger Kupper]

Clients laufen derzeit mit auf ltsp5.

[bau]

OK, nachdem der ltsp4 mit 600W-Netzteil und OHNE USV derzeit ohne Probleme läuft werde ich dem ltsp6 noch eine letzte Chance geben und ihm heute mittag ein stärkeres Netzteil einbauen. Anscheinend hängt das Problem an der Stromversrgung :-(

[Rüdiger Kupper]

Ich drücke uns die Daumen!

So allmählich sollten wir nämlich mal über einen Plan B nachdenken, falls wir das Problem wirklich nicht in den Griff bekommen. Wir brauchen Server, auf die wir uns verlassen können.

[Rüdiger Kupper]

So, ich hab mal die überflüssigen Pakete "network-manager" und "modem-manager" deinstalliert, hat aber leider keine Verbesserung gebracht:

Ein Reboot aller sieben Server eben hat ergeben, dass fünf ordentlich hochgefahren sind, zweo sind hängengeblieben (ltsp3 und 5). Ich denke, dass es momentan wirklich vom Zufall abhängt, und dass die Server in etwa 2/7 aller Fälle beim Hochfahren hängen bleiben :-(. Ursache ungeklärt, sieht stark nach race condition aus, aber welche Prozesse sich da einklemmen, weiß ich nicht.

[Rüdiger Kupper]

Ich glaub das nicht, ltsp6 ist schon wieder aus. Der hat ja anscheinend gerade größte Probleme.
Hast Du da jetzt schon das stärkere Netzteil eingebaut?

[bau]

Nein, ich wurde heute morgen von zwei Kollegen geholt, die waren im Raum tätig uns brauchten alle Rechner, da habe ich die Clients erstmal alle auf ltsp5 umgehängt.

[Rüdiger Kupper]

Hab's gesehen, danke!
Der 6er läuft jetzt wieder, Clients hängen aber noch auf ltsp5. Hat wohl derzeit keinen Sinn, sie wieder an den ltsp6 zu hängen. Der fällt ja schneller aus, als man hinterherkommt.

[bau]

leider Ausfall von ltsp4 - wieder das selbe Problem, nur diesmal seit drei Wochen zum ersten mal wieder :-(

[Rüdiger Kupper]

Replying to kup:

(Ah, Moment, die anderen Rechner hingen auch einmalig beim Reboot, ich weiß nicht warum, vielleicht ein kürzliches Update, das das verursacht. Nach nochmaligem Runter- und Hochfahren ging's dann jeweils wieder.

Hierfür öffne ich ein neues ticket:877.

[Rüdiger Kupper]

ltsp4 ist soeben wieder ausgefallen.

[bau]

ja, weil Baumi ihn ausgeschaltet hat :-)
Jetzt läuft ein Gigabyte 970A-DS3 in ihm, sonst ist alles genau gleich wie vorher.
Mal sehen, was der dazu sagt!

[bau]

Holger Baumhof schreibt mir grade zurück, dass er genau das Board in letzter Zeit mehrmals ohne Probleme verbaut hat (mit 6core Bulldozer und Kingston KVR Speicher).
Er verwendet das auch an seiner Schule als zentralen paedML-Server ohne größere Probleme (er hat auch nur SATA-Platten im Einsatz (WD 2TB Platten mit nur 5400U/min). Ich denke, da können wir mit unserer Hardware anfangen.

[Rüdiger Kupper]

Herr Jocob hatte noch einen Vorschlag, was man testen könnte, bevor wir den ltsp6 virtualisieren:

Platten aus dem ltsp6 und ltsp5 tauschen. Dann wird der ltsp5 zum ltsp6 und umgekehrt. Dann beide in den Produktivbetrieb nehmen.
Wenn dann wieder die gleiche Maschine wie zuvor ausfällt (dann also ltsp5), dann liegt es sicher an der Hardware des Servers. Fällt stattdessen die andere Maschine aus (die dann ltsp6 spielt), dann liegt es *nicht* am Server, sondern an unserem Netzwerk oder irgend etwas anderem.

Was hältst Du davon, das vorher noch auszuprobieren?

[bau]

OK, das wäre noch eine Variante, die wir ausprobieren können.
Ich werde dann mal die Platten tauschen und die Kisten hochfahren. Test kann natürlich erst nach den Ferien gelingen, da die Kisten nur im Realbetrieb ausfallen.

[bau]

ACHTUNG: Jetzt sind die Platten getauscht:

OBEN: ltsp6
MITTE: ltsp5
UNTEN: ltsp7 (wie bisher)

Mal sehen, was nach den Ferien passiert!

[Rüdiger Kupper]

Okay, ich hab davon nichts bemerkt, konnte mich heute wie gewohnt remote einloggen.

Also nur um sicherzugehen:
Das heißt

• die Maschine, die ich jetzt als ltsp5 sehe, ist die, die immer ausgefallen ist
• die Maschine, die ich jetzt als ltsp6 sehe, ist der ehemalige ltsp5

Derzeit installiere ich eine umfangreiche Benchmark-Testsuite auf allen sieben Rechnern. Bin mal gespannt, was die für Ergebnisse liefert.

[bau]

Ja, ltsp5 ist der mittlere, wenn die hardware streikt, wird am Montag dieser ausfallen, ltsp6 sollte weiterlaufen. Mal sehen.

[Rüdiger Kupper]

So auf den sieben Servern läuft jetzt gerade der Benchmark, also bitte grade nichts aufwändiges darauf laufen lassen.

Es handelt sich um das Programm ​Phoronix Test Suite. Das ist zwar etwas fummelig zu installieren, weil es die einzelnen Tests aus dem Internet nachlädt, bietet aber so viele Tests wie man sich nur wünschen kann. Komplette Sätze von Tests sind in sog. "suites" zusammengefasst, von denen es ebenfalls Unmengen gibt: ​http://openbenchmarking.org/suites/pts.

Ich lasse gerade mal die Suite "linux-system" durchlaufen, die die generelle Performance eines Linux-Systems testet. Die erwartete Laufzeit ist 5 Stunden, das macht also so einiges.

Die Testergebnisse erhält man nachher als Vergleichsdiagramm im Browser, als PDF, oder man kann sie auf ​http://openbenchmarking.org hochladen.

[Rüdiger Kupper]

Tssssssssss, ltsp3 ist jetzt bei Test 3 von 29, alle anderen sind bereits bei Test 6 von 29!

Was ist mit dem???

[Rüdiger Kupper]

Okay, der C-Ray-Test (Ray-Tracing Benchmark) macht eine Load von 110. Interessant.

[Rüdiger Kupper]

Hier ist das ​Testergebnis im Vergleich der sieben Server.
Ltsp3 zeigt in den meisten Tests keine relevante Abweichung, aber es fällt auf, dass die Schwankungen dort meist größer sind als bei den anderen (siehe Fehlerbalken). Bei einem Test fällt er aber eklatant aus der Reihe: postgreSQL! (Ganz unten.)

Außerdem interessant finde ich, dass für die sieben Server teilweise unterschiedliche Maschinendaten übermittelt wurde (siehe Übersicht ganz oben). ltsp4 hat das andere Mainboard, ltsp1 hat einen anderen Monitor und läuft daher in einer anderen Auflösung. Aber wieso berichtet ltsp7 eine andere Grafikkarte? Und wieso sagt ltsp1 "Unity 2D", ltsp5 "Unity" und alle anderen gar nichts?

[Rüdiger Kupper]

Aber: Keiner der Rechner ist unter der Belastung abgeschmiert.

Jetzt läuft gerade die "memory"-Testsuite:

"The system memory test suite consists of tests designed to test the computer's system memory (RAM) performance. Among these tests are RAMspeed and Bandwidth."

Danach kommt die networking-Suite dran. Und dann gibt's auch noch eine speziell für LtspServer.

[Rüdiger Kupper]

-> siehe LtspServerBenchmark

[Rüdiger Kupper]

Replying to bau:

Ja, ltsp5 ist der mittlere, wenn die hardware streikt, wird am Montag dieser ausfallen, ltsp6 sollte weiterlaufen. Mal sehen.

Bingo: ltsp5 ist heute gegen 14 Uhr ausgefallen. Das zeigt, dass es an der Maschine liegt, nicht an unserer Umgebung (danke an Sebastian für die Idee). Zudem können wir die Festplatten als Ursache schonmal ausschließen, denn das sind ja wirklich die vom ehemaligen ltsp5, der vorher kein Problem gemacht hat.

Es muss also etwas hardwaremäßiges geben, was den einen Server von den anderen unterscheidet.

@bau: Würde dieser Test die Mindfactory-Leute überzeugen, die Maschine auszutauschen? Es beweist, dass sie uns jedenfalls nicht sieben identische, arbeitsfähige Rechner geschickt haben.

[Rüdiger Kupper]

Achso, eine mögliche Komponente aus der Umegbung könnte es doch noch sein: der Switch bzw die Kabel zwischen Switch und Server. Wir sollten jetzt also einfach nochmal die Ethernetkabel vom Switch zu ltsp5/ltsp6 vertauschen -- nur für den Fall, dass das "tödliche Signal" über das Kabel kommt, das derzeit zur mittleren Maschine führt.

Fallt danach wieder die mittlere Maschine aus, liegt es auch daran nicht.

[Rüdiger Kupper]

Okay, die gleiche Maschine (ltsp5) ist wieder ausgefallen, und wieder zu gleichen Zeit, gegen 14:00.
Am Switch liegt es demnach auch nicht.

Die Regelmäßiglkeit ist bemerkenswertk, diese eine Maschine fällt inzwischen täglich aus, und immer gegen 14 Uhr.

[Rüdiger Kupper]

Die Clients von ltsp5 werden jetzt wieder von ltsp6 bedient.

[bau]

Ich habe die Platten wieder getauscht, und die USV am mittleren wieder angeschlossen, jetzt ist alles wieder wie gewohnt:

Oben: ltsp5 (128a)
Mitte: proxmoxltsp6 (10.32.2.106) unter ltsp6 (128b) - muss noch aufgesetzt werden
Unten: ltsp7 (128c)

Siehe auch Ticket #897

[bau]

proxmoxltsp6 war ohne Last nach einem Betriebstag aus!
Ich habe die Hardware ausgetauscht (ltsp5 und 6):

• Hardware von ltsp5 ist in ltsp4 gewandert (dort ist es wichtiger, dass es tut!)
• Hardware von ltsp6 war offensichtlich defekt -> Reklamation
• Hardware von ltsp4 (GigabyteBoard) ist in den künftigen PaedML gewandert

[Rüdiger Kupper]

bau hat (hoffentlich!) den Schwachpunkt bei proxmoxltsp6 ausfindig gemacht, es scheint das Netzteil zu sein. Derzeit läuft der Rechner mit neuem Netzteil stabil, ich schließe das Ticket einstweilen.

[bau]

Schock am morgen: ltsp6 und proxmoxltsp6 sind nicht erreichbar!
Erleichterung beim Besuch des Servers: Die zweite USV hat das zeitliche gesegnet - scheint eine Fehlproduktion zu sein!