Ubuntu 13.10 muckt...

[jas]

Ubuntu 13.10 ist extrem schwerfällig (zumindest in 5.53). Die Anmeldung dauert Ewigkeiten, die Maus verschwindet, bestimmte Befehle werden mit extremer Verzögerung ausgeführt (z.B. Abmeldung --> Probleme mit dem Gnome) oder funktionieren schlicht nicht (ebenfalls Abmeldung).
Leider sind die Mängel so schwerwiegend, dass ein Arbeiten (z.B. Schülerpräsentationen) im Unterricht unmöglich ist.

[Rüdiger Kupper]

Die Probleme scheinen zu kommen und zu gehen.

• Heute in der 3. Stunde hatte ich ebenfalls zuerst eine lange Login-Wartezeit in der NwT (LtspServer 4), dann hatte ich das Mausproblem, dann klappte der Logout nicht -- aber von dort unten war die Verbindung schon immer beeinträchtigt.
• Kurz darauf in der Pause an meinem Client im LZ (LtspServer 1) lief alles wie gschmiert: schneller Login, Zeiger ist da, schneller Logout.
• Ebenso in der 5. Stunde in Raum 5.03 (LtspServer 1)
• Kollegin Morgenstern konnte sich in der ersten Stunde gar nicht einloggen. Wenige Minuten später dann aber problemlos.
• Kollege Ortmann berichtet, dass er den Klassenraumrechner wie gewohnt benutzen konnte, ohne Probleme.
• Er war auch mit einer Schülergruppe im oberen Computerraum und die Schüler konnten sich normal einloggen und Internetrecherche machen.

D.h.: Die Probleme treten (mal wieder) nur manchmal auf, was die Suche nach der Ursache erschwert. Prinzipiell scheint die Software ja zu funktionieren, denn sonst müsste das Problem ja immer da sein. Es ist also kein prinzipielles Problem mit Ubuntu 13.10.

@jas: An welchen Rechnern hast Du Dich eingeloggt, also, an welchem LtspServer? Vielleicht können wir das Problem auf einen Server einschränken. Server 4 hat z.B. gestern schon Probleme gemacht, und das war auch der, wo ich heute morgen Schwierigkeiten hatte.

Wenn wir's nicht auf einen Server einschränlen können, müssen wir wieder mal nach Netzwerkproblemen suchen (Kabel, Switch, etc.)

[jas]

Wenn ich das richtig in erinnerung habe, war das im Raum 5.53 und da ich den Rechner mehrmals neustarten musste, meine ich mich auch mit relativ hoher Sicherheit an Ltsp4 zu erinnern. Das müsste der an diesem Rechner eingestellte Standardserver sein.

[Rüdiger Kupper]

Dann nehmen wir ltsp4 vielleicht mal genauer unter die Lupe. Das war auch der mit dem USB-Fehler im Syslog, und der neulich nicht booten wollte.

[bau]

Heute am ltsp4 / Raum 5.44

• Kamera funktioniert, Workaround mit dem Fenster herumwackeln ist OK, Fenster muss aber von Hand großgezogen werden und dann nochmals gewackelt
• Login dauert einfach zu lange, habe ich mal vorab gemacht
• Beim logout meldet sich ein hängender Gnome-Einstellungsdienst - ich denke mal, der ist der Übeltäter ansonsten dauert der Logout auch einfach zu lange

[Rüdiger Kupper]

Replying to bau:

Heute am ltsp4 / Raum 5.44

• Kamera funktioniert, Workaround mit dem Fenster herumwackeln ist OK, Fenster muss aber von Hand großgezogen werden und dann nochmals gewackelt

Da muss ich mal nach dem Config-File schauen, vielleicht haben sich da in der neuen Version Optionen geändert. Denn das Fenster müsste auf alle Fälle von Anfang an groß sein.

• Login dauert einfach zu lange, habe ich mal vorab gemacht
• Beim logout meldet sich ein hängender Gnome-Einstellungsdienst - ich denke mal, der ist der Übeltäter

Ziemlich sicher. Leider ist dieser "Einstellungsdienst" aber so eine Art eierlegender Wollmilchsau, der startet alle möglichen "Plugins", die den Desktop organisieren, vom Hintergrundbild über den Mauszeiger über Soundsteuerung bis hin zu sozialen Netzwerken. Welche davon wir brauchen/wollen/abschalten müssen, muss ich erst mal durch trial-and-error herausfinden.

ansonsten dauert der Logout auch einfach zu lange

Hängt ziemlich sicher mit dem noch hängenden Einstellungsdienst zusammen.

Wir sollten aber auf alle Fälle auch schauen, ob mit LTSP4 etwas an der Hardware nicht stimmt, denn das scheint der zu sein, der die meisten Probleme macht (oder aktivsten Nutzer hat ;-) ).

[bau]

Test in 5.19 (ltsp2): Anmelden dauert nicht ganz so lange, aber immerhin noch fast 40 Sekunden

[bau]

Vorschlag:
Wir virtualiseren den ltsp4 jetzt. Die Vorteile sind ja klar, ein weiterer ist, dass bei einem Update-Desaster mit einigen Schritten der alte Server hergestellt werden kann (z.B. einfach andere virtuelle festplatte einhängen und es ist wieder das alte System).

• USB-Stick mit rsync-Script zum Clonen eines ProxMox
  • damit kommt dann ein komplett funktionsfähiger LTSP mit
  • dabei: Anpassung des Rechnernamens und der IP des ProxMox sowie der conf-Datei für den virtuellen Host
• Script zur Anpassung des virtuellen LTSP-Hosts auf dem ProxMox
  • mounten der virtuellen Platte auf dem ProxMox
  • Anpassen
  • umounten
  • starten
• Script zum rsync-Clonen eines (virtuellen) LTSP-Servers auf einen anderen (virtuellen) LTSP-Server auf dem ProxMox
  • mounten der virtuellen Platte auf dem ProxMox
  • rsync von einem anderen LTSP
  • Anpassen
  • umounten
  • starten

[Rüdiger Kupper]

Aktueller Eindruck: Heute läuft das ganze bei mir erheblich besser -- selbst am Client in der NwT (an ltsp4). Ich konnte mich mehrfach hintereinander ein- und ausloggen, beim Login dauert es nur wenige Sekunden (ich vermute, bis die Mounts stehen), Logout klappt unmittelbar.

Ich habe gestern ein Update gemacht, und damit kam ein Bugfix, der auch den Gnome-Einstellungsdienst betraf und einen Hänger beim Login verursacht hat.

Vielleicht war das ja das Problem. Schreibt mal, ob ihr noch große Verzögerungen beim Ein- und Ausloggen feststellt.

[bau]

Perfekt :-)
Der Login dauert nun 20 Sekunden - auch bootet mein PC in der Chemie nun wieder gewohnt schnell!
Ich denke, das war's!

[bau]

Mit dem Update scheinen die Probleme vorbei zu sein.

[jas]

Super, Danke :-)

[Rüdiger Kupper]

An ltsp4 scheinen die Probleme beim Einloggen nach wie vor am größten zu sein. Gestern hatte ich in 5.54 regelmäßig Anmeldezeiten von ca. 1 Minute. Martina Vey berichtet heute wieder das selbe.
An ltsp1 und ltsp7 hatte ich heute keinerlei Probleme.

Also: ltsp4 wird virtualisiert. Wir könnten auch probeweise die Clients im 4. U auf einen anderen Server hängen (müssen wir ohnehin tun, während wir an ltsp4 herumschrauben).

Wenn danach noch immer im 4. U verstärkt Probleme auftreten, wissen wir, dass es nicht am Server, sondern an den Kabeln im 4. U liegt.

[bau]

Komisches Anmeldezeitenproblem:
Heute in Musik 2.03:

• booten (dauert recht lange)
• einloggen von bau dauert eine gefühlte Ewigkeit
• direkt im Anschluss: Einloggen von jun - geht flott
• nochmals: ebenfalls flott!

[bau]

Grade bin ich in 5.43:

• Anmelden dauert ziemlich lange!
• Komisch: zunächst kommen nicht die runden Gnome-Buttons in Thunderbird, erst nach einem kleinen Ruck habe ich dann auch überall die runde Optik - da hängt doch was!
• Beim Ausloggen hing wieder der Gnome-Einstellungsdienst

[Rüdiger Kupper]

Dafür, das typische Ubuntu-Erscheinungsbild ("Thema") zu laden, ist ebenfalls der GNOME-Einstellungsdienst zuständig. Was Du gesehen hast, war das Default-Thema. Das bedeutet, dass das entsprechende Plugin zu dieser Zeit noch nicht gelaufen war -- sicher deshalb, weil ein anderes "hing". Ich hab diesen Effekt auch schon beobachtet.

Ich glaube aber nicht, dass der GNOME-Einstellungsdienst diesmal etwas dafür kann: Wir haben mal wieder intermittierende Netzwerkprobleme. Das Netz scheint vorübergehend völlig blockiert zu sein. Dann dauert der Login lange, und einer der GNOME-Dienste, der ebenfalls aufs Netz zugreift, hängt, bis das Netz wieder frei ist.
Ich habe in den letzten Tagen auch das Problem, dass meine cssh-Terminals plötzlich und unerwartet einfrieren. Das ist mir heute gleich mehrfach passiert. Auch hier vermute ich ein verstopftes Netz.

Ich denke, wir sollten auf die Suche nach einem "Übeltäter" im Netzwerk gehen (im Kreis gestecktes Kabel, Switch, Wackelkontakt, etc.)

[Rüdiger Kupper]

Heute völlig flüssiges Einloggen, selbst in der NwT, wo es sonst Probleme gab (ltsp4).
@bau: Hast Du irgend etwas verändert?

[bau]

Heute scheint die Sonne :-)
Geändert habe ich rein garnichts! Ich werde heute Mittag aber mal die Verbindungen checken und mich vor allem mal endlich mit den Einstellungen der Cisco-Switche beschäftigen!

[bau]

Testergebnis:

• Anmeldung als bau dauert statistisch gestreut zwischen 20 und 90 Sekunden
• Anmeldung am LTSPL1 als linadmin geht fix (5-10 Sekunden)
• umount des /home/teachers und Anlegen von /home/teachers/bau: Anmelden geht fix (5-10 Sekunden)
• Anpassung des pam_mount auf CIFS vom paedml nach ~ Anmeldung geht rechts fix (<20 Sekunden)
• Habe noch /etc/fstab so angepasst, dass wegder /home/students noch /home/teachers gemountet wird

Mal Abwarten, wie das nun tut :-)
Werde das Ganze demnächst an den anderen LTSP einrichten! Zunächst Test im LZ.

[bau]

Zur Gnome-Shell finde ich grade:
"Mit Hilfe des Programms Zeitgeist versucht die GNOME-Shell, Dokumente zu indizieren und soll es später ermöglichen, die Dokumente direkt zu öffnen – ohne sie im Dateimanager suchen oder öffnen zu müssen"

Als ich garde mal auf ltsp1 nachgesehen habe hingen dort immernoch zwei zeitgeist-Prozesse von mir, wegen derer mein HomeVZ nicht ausgehängt werden konnte. Als ich die abgeschossen hatte ließ sich auch das Home aushängen. Ich bin dafür, den zeitgeist abzuschalten!

[bau]

auf ltsp3 lässt sich das HomeVZ von hoppentin nicht aushängen. Ein ps aux|grep zeitgeist ergibt einen hängenden Prozess:

13117    26084  0.0  0.0      0     0 ?        D    Nov29   0:00 [zeitgeist-datah]

dieser lässt sich noch nicht einmal mit kill -9 26084 abschießen! Ich denke, der Zeitgeist muss dringend abgeschaltet werden!

[jas]

Querverweis zu Kritik an "Zeitgeist": #1053

[Rüdiger Kupper]

Okay, werde mal probieren, den Dienst zu deaktivieren.

[bau]

Maßnahmen ergriffen:

• /etc/xdg/autostart/zeitgeist-datahub.desktop nach /etc/xdg/autostart/autostart-disabled verschoben
• /usr/bin/zeitgeist-daemon und zeitgeist-datahub nach /usr/bin/disabled verschoben

somit kann zeitgeist nicht mehr gestartet werden.
Im Netz wird immer wieder von nicht unerheblichen Performancegewinnen durch Deaktivierung berichtet.
Falls das bei uns auch zutrifft muss in Zukunft bei Updates auf den zeitgeist geachtet werden!

[Rüdiger Kupper]

Sieht man schon eine Verbesserung?

Wenn ja, würde ich das Paket "zeitgeist-core" einfach komplett entfernen. Das ist etwas sauberer, als das nur das Executable zu verschieben. Momentan beschweren sich nämlich alle Programme, die Zeitgeist verwenden wollen, dass der "zeitgeist-daemon" nicht gestartet werden kann. Wer weiß, ob das dann wieder blöde Nebeneffekte hat.

Ich habe grade mal geschaut, was alles mit entfernt würde, wenn man "zeitgeist-core" entfernt: Nur Zeitgeist, das "gnome-activity-journal" und einige Plugins für Prgramme, die die Zeitgeist-Anbindung machen. Nichts elementares also.

Wir beobachten jetzt mal, was passiert.

[bau]

Ich merke, dass die LTSP-Server performanter arbeiten. das merke ich sogar in einer cssh, die antworten plötzlich direkt und nicht erst nach einer Schrecksekunde. Auf LTSP4 waren noch Prozesse gehängt, dort hatte ich einen Hänger beim Login heute morgen. Ich konnte nach dem Abschießen einiger Prozesse dann aber die HomeVZ's wieder aushängen. Mal sehen, ob in Zukunft weitere Hänger da sind oder ob die nicht mehr beobachtet werden können.

[bau]

Leider hängen auf den ltsp wieder mounts:

• ltsp1/ros wegen einem knotify-Prozess
• ltsp7/guentherm2 und kaelberer ohne sichtbare Prozesse, dafür gibt es mehrere Prozesse ohne gültigen User

hier war es 11761 als User, es hing ein plank und ein at-spi-bus-launcher bei kaelberer und bei guentherm2 die gleichen Prozesse unter UID 11732

Nach dem kill -9 ließen sich die Homes problemlos aushängen!

[bau]

Eventuell hängt dieses Problem an den Netzwerkswitchen in SP1,3 und 4 (siehe #1063)

[bau]

Problem hängt definitiv mit den Switchen zusammen. Das Problem hatte sich verschlimmert nach einem BIOS-Update. In den Switchen haben wir nun Flowcontrol (Ticket #1063) auf den Gigabit-Anschlüssen ausgeschaltet. In U3 und U4 hingen Switch und Server, wir hoffen, dass die Entfernung des nicht mehr benötigten Kernelmoduls für den RealTek-NIC 8168 (Ticket #692) das Wiederauftauchen des Problem behebt. Wenn nicht, muss auch auf dem zentralen Switch CISCO0027 Flowcontrol ausgeschaltet werden.

[Rüdiger Kupper]

Die ganze Sache ist zwar stabiler, aber noch weit entfernt von reibungsloser Verwendbarkeit.

Beispiele:

• Kollege kroe hatte heute mehrfach wieder Probleme mit dem Sound:
  • Bei YouTube zunächst kein Ton
  • Habe den Client neu gebootet, dann gab's zunächst Ton
  • Wiedergabe eines Videos vom USB-Stick: Ton bricht zusammen und funktioniert auch später nicht mehr (Soundserver hat sich wohl verabschiedet)
  • Neuboot: Ton geht wieder
  • Wir haben dann das Video vom USB-Stick auf den Desktop kopiert und dort gestartet: Das klappt.

Es scheint, dass sich der Soundserver bei zu hoher Netzwerklast einfach verabschiedet (Bei Widergabe direkt vom Stick gehen ja die Daten zuerst über's Netz zum Server, von dort kommt Bild und Ton zurück). Immer dann haben die Kollegen keinen Ton.

Außerdem habe ich bei Kollege kroe eine Verzögerung beim Login beobachtet (nur ein paar Sekunden, aber verdächtig: Hintergrundbild war schon da, aber der Desktop reagiert für eine Weile nicht).

Im täglichen Unterrichtseinsatz gibt es also immer noch Hänger und Probleme, ich plädiere dafür, das Flowcontrol auf dem Hauptswitch auch mal abzuschalten und zu beobachten, ob das Auswirkungen hat.

[Rüdiger Kupper]

Zusatzinformation: Die Probleme von kroe waren im 3. U.

[bau]

OK, ich habe gestern von der KSK zwei cisco 4506 geschenkt bekommen (jeder im Neuwert von etwa 40T€, natürlich sind die jetzt zehn Jahre alt) - die sollen den Hauptswitch dann mal ersetzen

• ich würde zunächst den Hauptswitch auf Flowcontrol off setzen
• am Hauptswitch die Supervisor-Engine tauschen
• den Hauptswitch austauschen

[Rüdiger Kupper]

Replying to bau:

• ich würde zunächst den Hauptswitch auf Flowcontrol off setzen
• am Hauptswitch die Supervisor-Engine tauschen

Gut. An der Stelle sollten wir nochmal beobachten, ob sich was ändert.

• den Hauptswitch austauschen

Wie unterscheiden sich die neuen Ciscos vom alten Switch?

[bau]

Die 45'er Reihe ist neuer, wahrscheinlich schneller, wobei das auf jeden Fall auf die Supervisor-Engine ankommt.

[jas]

Eigentlich ist das Ausgansproblem gerade nicht mehr vorhanden oder? Für die Switchs sollten wir evtl. AusGründen der Übersicht ein eigenes Ticket öffnen. Was meint ihr?

[bau]

Ich schließe das Ticket, da die Hauptpropblematik durch Entfernen des NM-Applets und Nicht-Verwendung des Policy-KIT behoben zu sein scheinen.