Computerraumserver gehen in die Knie, wenn sich eine ganze Klasse gleichzeitig anmeldet

[Rüdiger Kupper]

bau berichtet, dass das Anmelden einer ganzen Klasse gleichzeitig in Raum 128 starke Verzögerungen zeigte. Nachdem alle Desktops gestartet waren, lief die Sache dann wieder flüssig.

[Rüdiger Kupper]

Jens, welche Klasse war das? Ich schaue gerade die Logs durch. Waren das Elfer?

[Rüdiger Kupper]

In den Logs sehe ich folgende verdächtige Einträge immer nachdem sich jemand angemeldet hat:

Dec 19 17:04:24 ltsp118 kernel: [91082.385809] ica[30122] general protection ip:7f33428d66dc sp:7fff4236cab0 error:0 in libgtk-x11-2.0.so.0.2400.6[7f334281e000+42f000]
Dec 19 17:04:26 ltsp118 kernel: [91084.362202] type=1400 audit(1324310666.854:50): apparmor="DENIED" operation="mkdir" parent=30185 profile="/usr/lib/telepathy/mission-control-5" name="/home/teachers/kup/.mission-control/" pid=30186 comm="mission-control" requested_mask="c" denied_mask="c" fsuid=12083 ouid=12083

Außerdem sehe ich vereinzelte Abschnitte der Form

Dec 19 15:40:08 ltsp118 NetworkManager[1231]: <warn> error requesting auth for org.freedesktop.NetworkManager.wifi.share.open: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.638': no such name

Das lässt auf Probleme mit den folgenden Diensten schließen:

1. Italc (Prozess ica)
2. Telepathy/Empathy
3. NetworkManager

• Italc ist noch nicht konfiguriert, ist aber schon als Dienst eingetragen, der bei der Anmeldung ausgeführt wird. -> vorerst abschalten
• Teleathy und Empathy sind die Dienste zur automatischen Anmeldung bei sozialen Netzwerken -> brauchen wir nicht, deaktivieren!
• NetworkManager brauchen wir ebenfalls nicht, weil sie Server alle statische IPs haben -> deaktivieren!

Natürlich ist nicht gesagt, dass das die Dienste sind, die das Problem machen.

[bau]

Hallo Rüdiger,

das waren die 5c-Leute heute in der 3./4. Stunde.

[Rüdiger Kupper]

Syslog des betreffenden Tages

[Rüdiger Kupper]

Syslog des betreffenden Tages

[Rüdiger Kupper]

Syslog des betreffenden Tages

[Rüdiger Kupper]

In den Syslogs der LTServer sehe ich immer wieder lange Sequenzen der folgenden Art:
attachment:syslog-2011-12-19--named-error​.
Sobald eine Verbindung von einem Client aus hergestellt wird, versucht der Server offenbar, den Namen des Clients per DNS aufzulösen, und das mißlingt. Wie Du siehst werden all diese paarhundert Anfragen in der selben Sekunde gemacht und schlagen alle fehl. Das wirkt zumindest komisch.

• warum will der Server den Namen des Clients überhaupt auflösen?
• sollte das funktionieren (liegt bei uns also ein Fehler vor), oder ist es vielleicht völlig in Ordnung, dass der Name nicht aufgelöst werden kann
• erzeugt diese Sache vielleicht den Hänger beim Einloggen? Scheint den Server ja nicht länger als eine Sekunde zu beanspruchen.

Aber fällt Dir vielleicht irgendwas ein, was an unserer DHCP/bind-Konfiguration noch komisch sein könnte? Noch irgend ein fehlender Eintrag in der DHCP-conf?

Der DHCP-Server sagt ja dem Client, wie er heißt. Sollte der Server dann "seine" Clients auch unter diesen Namen finden?

[bau]

Die Auflösung der Client-Namen wäre kein größeres Problem. Die paedml macht das mit den aufgenommenen Clients auch so, dass die in der DNS-Datei eingetragen werden und dann die Namensauflösung funktioniert. Vielleicht sollten wir das einfach mal so machen?

[Rüdiger Kupper]

Erklär bitte nochmal, wie die PädML das macht. In welche Datei sollen die Namen geschrieben werden?

[Rüdiger Kupper]

Hier gibt es Informationen darüber, wie man dem DCHP-Server beibringt, die neu vergebenen Namen dem DNS-Server mitzuteilen. Bei den nicht-aufgenommenen Clients funktioniert das ja, sagst Du. Wieso nutzt die paedml das nicht, sondern legt statische Files an?

​http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/

[Rüdiger Kupper]

Replying to kup:

• Italc ist noch nicht konfiguriert, ist aber schon als Dienst eingetragen, der bei der Anmeldung ausgeführt wird. -> vorerst abschalten

Das ist erledigt, der Dienst "ica" wird nun defaultmäßig nicht mehr beim Login gestartet. Erreicht durch einen Eintrag in /usr/share/gnome/autostart/ica.desktop

X-GNOME-Autostart-enabled=false

(Siehe auch Ticket #138)

[Rüdiger Kupper]

Querverweis auf Ticket #489.

[Rüdiger Kupper]

Querverweis: #569

[Rüdiger Kupper]

Das Problem scheint nicht mehr zu existieren, ich konnte mich mit einer ganzen Klasse im Computerraum einloggen, ohne dass größere Verzögerungen aufgetreten sind.

[Rüdiger Kupper]

Das Problem besteht weiter, zuletzt aufgetreten, als rue und ber mit ihren Schülern gleichzeitig im Raum 128 arbeiten wollten.

Mögliche Ursachen

1. Beim Anmelden machen alle Nutzer zeitgleich Zugriff auf ihre Home-Verzeichnisse, die vom paedml per NFS serviert werden. Das kann aus mehreren Gründen bei konkurrierenden Zugriffen zu langsam sein:

• Festplatten des NFS-Servers zu langsam
• Netzwerk zwischen paedml und LtspServern zu langsam oder Netzwerkprobleme

1. Beim Anmelden laufen ev. einige Standardprozesse, die Internetzugriffe machen. Die gehen alle gleichzeitig durch den IPCop raus, also kann auch der ein Engpass sein.

• Social-Networking-Client (gwibber)
• Ubuntu One Client (läuft der überhaupt, wenn nicht vom Nutzer eingerichtet?)
• Der Ubuntu Software Updater bzw. dessen Notifier läuft vielleicht auch für jeden Client(?)

[Rüdiger Kupper]

• Die Festplatten des NFS-Servers sind garantiert ein Engpass.
• Das veraltete NFS3 sollte durch NFS4 ersetzt werden (geht aber wohl erst nach einem Serverupdate)

[Rüdiger Kupper]

Querverweis: Weitere mögliche Ursache: #1063

[Rüdiger Kupper]

Replying to kup:

• Social-Networking-Client (gwibber)
• Der Ubuntu Software Updater bzw. dessen Notifier läuft vielleicht auch für jeden Client(?)

Gwibber/Telepathy und der Software Updater wurden deaktiviert, siehe #569.

[Rüdiger Kupper]

Heute hat sich jas mit 14 Schülern im oberen Computerraum angemeldet. Wieder dauert es minutenlang, bis die Nutzer einen Firefox gestartet haben.

Ich habe beobachtet, dass die Load auf den Rechnern im Bereich 10-20 war (bei je 7 oder 8 Nutzern!!). Nach mehreren Minuten fiel sie dann aber plötzlich gleichzeitig auf allen drei Servern auf normale Werte ab. Was auch immer die Server lahmgelegt hat war dann plötzlich vorbei.

Ich fürchte, wir haben derzeit wieder generelle Netzwerkprobleme im Haus.

Querverweis: #1091

Bitte auch erledigen: #1063

[Rüdiger Kupper]

Heute mit meinem NwT-Kurs: Gleiches Szenario, überhaupt kein Problem. Meine 16 Schüler haben sich gleichzeitig eingeloggt und Firefox gestartet. Man hat nicht gerade das Gefühl, dass man vor einem rasend schnellen System sitzt, aber nichts hat besonders lange gedauert. Alle konnten normal arbeiten. Keine überlasteten Server.
In der zweiten Stunde kamen noch Ruben Pallesches 8 Schüler hinzu, haben sich ebenfalls eingeloggt und Firefox gestartet, auch hier kein besonderes Problem.

Ich fühle mich mal wieder von unserem Netzwerk auf den Arm genommen....

[jas]

Hab mich heute mit etwa 25 Schülern eingeloggt, war gar kein Problem... später kamm dann eine weitere Klasse hinzu, sodass alle (bis auf die defekten) Rechner liefen. Ohne Probleme.
Lief der Server seit dem eigentlich durch, oder wurde er seit Montag mal rebootet?
Was natürlich rein spekulativ ist - heute war es kühler in dem Raum...

[bau]

Alle Server laufen seit Schuljahresbeginn durch. Das einzige, was ich geändert habe ist die Änderung am ipFire - kann es sein, dass die ltsp-Server ab und zu mal Internetzugang brauchen?

[Rüdiger Kupper]

Die LtspServer habe ich einmal neu gebootet, als ich auf CIFS umgestellt habe, also Dienstag Nacht.

Replying to bau:

Das einzige, was ich geändert habe ist die Änderung am ipFire - kann es sein, dass die ltsp-Server ab und zu mal Internetzugang brauchen?

• für die automatischen Sicherheitsupdates (aber die laufen ja über den 10.32.1.253-Proxy, oder?)
• die Mozilla-Produkte schicken möglicherweise anonyme Nutzungsdaten an Mozilla
• Firefox lädt hoffentlich nicht mehr die Liste vertrauensunwürdiger Sites lokal herunter (ist in den Einstellungen abgestellt)
• schickt Ubuntu vielleicht auch anonyme Nutzungsdaten an Canonical?
• Sofern die Nutzer das aktiviert haben, kann sich Ubuntu mit verschiedenen Kommunikations- oder Cloud-Diensten verbinden, die meisten Dienste hab ich aber schon rausgeschmissen

Also, im Zweifelsfall läuft da schon etwas beim Einloggen, doch nichts davon dürfte den Rechner lahmlegen, wenn keine Internetverbindung besteht. Geschweige denn, dass die Load auf einmal auf 20 steigt...

[Rüdiger Kupper]

Das Problem besteht in der beschriebenen Art nicht mehr, wir haben derzeit dafür Probleme, die auf die CIFS- und bind-Mounts der Linuxmusterlösung zurückzuführen sind (siehe zugehörige Tickets). Ich schließe daher dieses Ticket.