LtspServer bleiben beim booten hängen

[bau]

Das Phänomen hattest du berichtet, dass es nach einem Update auftritt. Bislang half immer ein Reboot, dann kam er weiter. ltsp6 hängt jetzt aber zuverlässig beim mounten. Anpingen lässt er sich, weiter geht nichts.

[Rüdiger Kupper]

???
Ich hab gegenüber den anderen Servern nichts geändert.
Das war bei allen Maschinen einmal beim Booten aufgetreten, beim zweiten Versuch ging's jeweils.
Ich hab die Maschinen jweils mit der Tastensequenz
STRG-DRUCK-<Taste> (mit nacheinander R;E;I;S;U;B) neu gestartet.

Woran könnte der Hänger liegen?

[Rüdiger Kupper]

Kann's das r8168-Modul sein?

[bau]

Meinst du das könnte sein?
OK, dann müsstest du mal das Modul deaktivieren - vielleicht bringt's was?

[Rüdiger Kupper]

Nur geraten. Irgend etwas geht ja scheinbar beim hochfahren des Netzwerks schief. Obwohl: der Ping funktioniert ja, das Interface ist also oben und der Rechner kennt seine IP.

Ich tappe im Dunkeln. Wenn der Rechner wieder oben ist, versuche ich mal in den Logs zu finden, wo genau er hing.

[bau]

Zunächst mal muss er halt mal wider hochkommen - Neustart bringt grade halt nix! (oder geht das mit dem kryptischen Tastendrücken?)

[Rüdiger Kupper]

Die kryptischen Tastendrücke sind eine Sequenz von Kernel-Requests, mit denen man Kommandos direkt an den Linux-Kernel senden kann. Wenn ein Linux-Rechner hängt kann man ihn damit z.B. sauber herunterfahren und neu booten (​wikipedia:Magic_SysRq_key). Das hab ich mit dem hängenden Rechnern immer gemacht und beim nächsten Versuch sind sie hochgefahren.
Aber wie dem auch sei, da ist trotzdem etwas faul, denn die Prozedur hatte ich bei ltsp6 schon einmal durchgeführt, er hängt jetzt also schon zum wiederholten mal. Da muss es beim Hochfahren irgend eine race condition geben, die nur manchmal zum Hänger führt...

[Rüdiger Kupper]

Auf allen Servern sehe ich im dmesg-Log die folgenden Zeilen:

[   75.212777] init: isc-dhcp-server main process ended, respawning
[   75.309711] init: isc-dhcp-server main process (1655) terminated with status 1
[   75.309733] init: isc-dhcp-server respawning too fast, stopped

Die ersten zwei wiederholen sich etwa zehnmal, dann folgt die letzte Zeile.
Das ganze scheint die Kisten zwar nicht davon abzuhalten, trotzdem zu booten, aber es kommt mir dennoch seltsam vor. "isc-dhcp-server" ist der Dienst, der einen lokalen DHCP-Server startet. Die LtspServer versuchen also, einen eigenen DHCP-Server zu starten (der dann z.B. als Proxy für den Haupt-DHCP dienen kann). Wenn das liefe, müsste der paedml nicht jeden einzelnen Client bedienen, sondern die Clients würden die DHCP-Info von ihrem jeweiligen Server bekommen. Wäre sicher nicht schlecht.

Jedenfalls schlägt das fehl. Ich frage mich, ob es vielleicht etwas mit dem sporadischen Hängenbleiben zu tun haben könnte.

[Rüdiger Kupper]

Ahja, okay, aus dem syslog geht hervor, wieso der dhcp-Server nicht startet: Die Konfigurationsdatei enthält einfach keine Einträge, daher hat er nichts zu tun und startet gar nicht erst.

Das war aber schon immer so, hängt also vermutlich nicht mit den Startproblemen zusammen.

[bau]

Wenn der als Proxy definiert wird muss er ja aber immernoch Daten zum Haupt-DHCP senden - oder?
Woher weiß der Client denn überhaupt, er ihm Antwort gibt?
Ich denke, die DHCP's auf den Servern kannst du getrost ausschalten.

Leider hilft uns das noch nicht weiter, warum die hängen bleiben :-(

[Rüdiger Kupper]

Replying to bau:

Wenn der als Proxy definiert wird muss er ja aber immernoch Daten zum Haupt-DHCP senden - oder?

Richtig. Nur der Client braucht dann keinen Zugang zum Haupt-DHCP-Server, er bekommt seine PXE-Boot-Informationen direkt vom LtspServer. Das ist wohl dann sinnvoll, wenn man den Hauptserver entlasten will, oder wenn die Clients wirklich keinen ZUgang zum Hauptserver haben.

Woher weiß der Client denn überhaupt, er ihm Antwort gibt?

Vermutlich gar nicht. Muss er das wissen?

Ich denke, die DHCP's auf den Servern kannst du getrost ausschalten.

Leider hilft uns das noch nicht weiter, warum die hängen bleiben :-(

Genau. Ich tappe noch immer im Dunkeln. Es könnte mit den NFS-Mounts zusammenhängen. Ich frag mich nur, warum das Problem erst kürzlich aufgetaucht ist.

[Rüdiger Kupper]

Bugreport auf Launchpad eingereicht: ​​launchpad:1118447

[Rüdiger Kupper]

Auf den Bugreport kam die Antwort, es einmal mit dem neusten Linux-Kernel zu probieren. Den werde ich mal installieren, wenn ich Zeit habe.

Um zu testen, ob wirklich die NFS-Mounts das Problem sind, ist es wohl das einfachste, Du kommentierst in der /etc/fstab die NFS-Zeilen einfach aus, bevor Du die Rechner runterfährst.
Nach dem Hochfahren dann wieder einkommentieren und ein sudo mount -a machen.

[bau]

Test durchgeführt:
Immerhin bleibt der Server nicht beim Booten hängen und er zeigt, was ihm fehlt:
Er kann sein Netzwerk nicht starten, da das Modul r8168 nicht geladen wird (lsmod|grep r8169).
Wenn ich das Modul von Hand lade (modprobe r8169) kann ich problemlos die NFS-Shares reinmounten.
Frage bleibt also: Warum lädt der das Modul nicht?

[Rüdiger Kupper]

Ich denke, das ist eher eine Nebenwirkung des Test mit dem aktuellen Linux-Kernel, den ich heute Mittag noch durchgeführt habe. Ich habe den aktuellesten Kernel auf den Computerraumservern installiert und die drei Rechner danach zweimal neu gebootet: Bei allen sechs Versuchen sind die Rechner beim Hochfahren hängengeblieben. Das Problem verschärft sich also im aktuellen Kernel noch. Meine Beobachtungen habe ich im Bugreport ​​launchpad:1118447 festgehalten, so dass sich hoffentlich jemand darum kümmern kann.

Zuvor wurde das r8168-Modul meines Wissens geladen, ich denke, das Neukompilieren mit dem aktuellen Kernel hat irgend ein Problem gemacht. (Vorausgesetzt, Du warst an ltsp5-7, an den anderen hab ich nichts verändert!)

[bau]

Sorry, ich hatte nicht dazugeschrieben: Ich war am ltsp4!
Es hat also nichts mit dem neuen Kernel zu tun!

[Rüdiger Kupper]

Ach verd... mein Fehler: Ich hatte den neuen Kernel tatsächlich auf allen Kisten installiert, aber nur ltsp5-7 neu gebootet. Und dann hab ich den Kernel nur auf ltsp5-7 wieder entfernt...

D.h. Dein Rechner hat mit dem neuen Linux-Kernel gebootet, und für den gibt es keinerlei binäre Erweiterungen wie Kernelmodule.

Jetzt habe ich den neuen Kernel überall wieder entfernt.

[bau]

So, jetzt ist es amtlich:
Ich habe bei ltsp5,6 und 7 die SATA-Anbindung gecheckt (sda ober sdb unten) und bei ltsp7 vorher in der /etc/fstab die NFS-Shares auskommentiert - Der Server bootet durch und wartet auch nirgendwo minutenlang!
Anschließend Shares wieder rein, sudo mount -a, alle Shares sind da. Nochmals reboot und minutenlanges Warten (ich bin grade in der Chemie und weiß nicht, ob der hochgekommen ist).

Fazit:
Wir sollten die Shares in der fstab als noauto setzen und erst am Schluß des Bootens mounten!

[Rüdiger Kupper]

Alles klar, dann werd ich das mal in Angriff nehmen.
Gleichzeitig schreibe ich Deine Erfahrungen in den Upstream-Bugreport, denn da hat der Kernel offenbar ein Boot-Problem mit NFS.

[Rüdiger Kupper]

In den fstabs steht jetzt bei allen NFS-Mounts "noauto". Das Cronskript passe ich jetzt an.

[Rüdiger Kupper]

Das Skript mountet jetzt die Shares namentlich. Es wird jede Stunde per Cron aufgerufen, außerdem habe ich es in /etc/rc.local eingetragen, es müsste also beim Boot laufen.

[Rüdiger Kupper]

Der Workaround funktioniert, die Server booten normal und mounten dann per /etc/rc.local am Ende des Bootvorgangs die NFS-Shares.

[Rüdiger Kupper]

Da das Mouten beim Boot verlässlich zu klappen scheint, habe ich das Skript aus cron.daily entfernt:

linadmin@ltsp118:~$ sudo rm /etc/cron.hourly/kepler--mountall-workaround 

[Rüdiger Kupper]

Tsss, jetzt habe ich eben die Maschinen neu gebootet, und das rc.local-Skript wird brav ausgeführt, als ob nie etwas anderes gewesen wäre. Ich reaktiviere das Cronskript trotzdem, das schadet nicht:

linadmin@ltsp118:~$ cd /etc/cron.hourly/
linadmin@ltsp118:/etc/cron.hourly$ sudo ln -s /etc/init.d/kepler--mountall-workaround

[Rüdiger Kupper]

per Mail von bau:

kann man die Ausgabe des Scripts bitte an /dev/null leiten
wöchentlich über 1000 unnötige Mails nerven zu sehr.

Ups, natürlich.
Besser noch, das Skript spuckt nur dann etwas aus, wenn ein Verzeichnis nicht gemountet war und ist sonst still.

[Rüdiger Kupper]

Das Skript ist jetzt ruhig, außer ein Verzeichnis war nicht gemountet.

[Rüdiger Kupper]

Ich vermute, dieser Workaround wird inzwischen nicht mehr benötigt.
Bei Gelegenheit testen.

[Rüdiger Kupper]

Auf ltsp8 existierte der Workaround bisher nicht, und der Server ist niemals beim Booten hängengeblieben.
-> vermutlich kann der Workaround auch auf den anderen Rechnern entfernt werden:

1. noauto-Flags aus der /etc/fstab entfernen
2. Skriptaufruf aus /etc/rc.local entfernen

[bau]

Der Workaround war nur für die NFS-Shares benötigt worden.
Da wir aktuell ohne NFS auskommen (alle Einträge der fstab können auskommentiert werden / beim Login werkelt derzeit der pam_mount)!

[bau]

Server werden künftig nach und nach virtualisiert.
Problem dürfte damit erledigt sein!