Infosys stürzt ab

[Rüdiger Kupper]

Eben gerade lief an keinem Rechner im LZ mehr Infosys, die Sitzung schien überall abgestürzt zu sein. Dei scheint es keine Rolle zu spielen, ab es ein alter Rechner oder einer der Betarechner ist.
Beim Neustart der Rechner scheint es erst mal wie gewohnt zu starten.

Was könnte da zum Absturz führen?

[Rüdiger Kupper]

Weitere Probleme:

• an rechner-lz-01 startet InfoSys auf Konsole 12 (ist aber ein alter Rechner – verwirrend)
• an rechner-lz-05 startet InfoSys überhaupt nicht (cannot read from boot device – das ging aber doch neulich noch?)

Ich glaube, ich werde jetzt mal die restlichen drei Rechner im LZ auf Beta umstellen, dann müssen wir uns nur noch um eine Version des Systems kümmern, nicht zwei.

[bau]

An rechner-lz-01 haben wir ein svn update in /usr/local/sbin gemacht, somit wurde die Konsole nach 12 verlegt. Wurde 05 gesynct?, an 01 hat der svn update geholfen, damit das korrekte Script dort läuft (aber dann eben auf Konsole 12)

[Rüdiger Kupper]

Ja, es lief auf Konsole 12, aber eben erst wieder nach einem Neustart des Rechners. Als ich gestern ins LZ kam, war Infosys wie gesagt auf allen Rechnern abgestürzt. Irgend etwas scheint es also im Lauf des Tages zum Absturz gebracht zu haben. Irgend eine Idee, was das gewesen sein könnte?
–> im Auge behalten, ob es wieder passiert.

Und ja, ich hatte rechner 05 tatsächlich gesynct, jetzt, wo Du es sagtst. Warum lief dann Infosys nicht?

ANTWORT:

• Ich habe die Scripte abgeändert (z.B. Versionierung)
• Hast du das neue Image draufgepackt, dann sollte eigentlich das aktuelle Script enthalten sein und wir müssen mal prüfen, warum das dann nicht tat.
• Beim alten Image ist das alte Script enthalten und wird sicher nicht mehr funktionieren.

[bau]

Keine Ahnung, was zum Absturz geführt hat.
Manchmal stehen auf der 12. Konsole noch VirtualBox-Fehlermeldungen.
Ansonsten legt VirtualBox im HomeVZ von windows logs an, die vielleicht etwas hilfreiches enthalten.

[Rüdiger Kupper]

Gerade eben gleiches Phänomen:

• vor einer Stunde lief auf rechner-lz-05 Infosys auf Konsole 12
• eben gerade war es abegstürzt (die komplette virtuelle Maschine)
• wenn ich das nächste Mal Zeit habe, untersuche ich mal die Fehlermeldungen

[Rüdiger Kupper]

Okay:

• direkt nach dem Systemstart läuft Infosys. Man kann mit STRG-ALT-F1 und F12 hin- und herschalten
• ein Nutzer loggt sich bei Ubuntu ein
• drückt er dann STRG-ALT-F12, stürzt die Infosys-Sitzung ab

Argh!

[Rüdiger Kupper]

Das Problem tritt beim Wechseln zwischen X-Displays auf. Stellt man nämlich den gdm3-Greeter von Wayland auf X um, stürzt die Sitzung bereits beim ersten Wechselversuch ab, auch wenn niemand eingeloggt war.

Querverweis: #3379

[lehrer]

Hier sind die Fehlermeldungen:

root@rechner-lz-06:/home/teachers/lehrer# kepler--lehrer--start-infosys-session 
root@rechner-lz-06:/home/teachers/lehrer# 

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-148-generic x86_64 Ubuntu
Current Operating System: Linux rechner-lz-06 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 ro splash intel_idle.max_cstate=1 net.ifnames=0
Build Date: 03 June 2019  08:10:35AM
xorg-server 2:1.19.6-1ubuntu4.3 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.34.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Tue Dec 10 12:54:49 2019
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) [KMS] Kernel modesetting enabled.
Hole /cache/Win7.qed.version
 ... in /cache/ gefunden: Win7_20191130.qed
     Win7_20191130.qed soll erhalten bleiben
Ctorrent-Screen fuer Win7_20191130.qed läuft bereits.
Formatting '/cache/Win7_ballon.qed', fmt=qed size=107374182400 backing_file=/cache/Win7.qed cluster_size=65536
rm: das Entfernen von '/cache/Snapshots/*' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
VBoxManage: error: Cannot delete the machine state as the machine is not in the saved state (machine state: Aborted)
VBoxManage: error: Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component SessionMachine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "DiscardSavedState(true )" at line 662 of file VBoxManageMisc.cpp
Qt WARNING: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-windows'
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
Unable to retrieve master
(EE) 
Fatal server error:
(EE) EnterVT failed for screen 0
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
(EE) 
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
Qt WARNING: The X11 connection broke: I/O error (code 1)
Qt WARNING: The X11 connection broke: I/O error (code 1)
XIO:  fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server ":1"
      after 32 requests (32 known processed) with 0 events remaining.
XIO:  fatal IO error 0 (Erfolg) on X server ":1"
      after 2651 requests (2651 known processed) with 0 events remaining.
xinit: connection to X server lost

[Rüdiger Kupper]

Mögüicherweise wichtig:

​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801605

[Rüdiger Kupper]

Ah, das hier scheint genau unser Problem zu sein:
​https://askubuntu.com/questions/617885/switching-to-another-tty-after-running-startx-and-returning-breaks-xorg

[Rüdiger Kupper]

Auch interessant:
​https://unix.stackexchange.com/questions/448787/why-is-vt-switching-not-working-for-xorg-run-as-root

[Rüdiger Kupper]

Also, es scheint daran zu liegen, dass logind die Terminals dynamisch verwaltet und nicht mitbekommt, dass wir auf einem einen X-Server gestartet haben. Beim Zurückschalten versucht es dann wohl dort ein Textterminal zu starten und killt unseren Prozess. So ungefähr.

[Rüdiger Kupper]

Ich kehre aufgrund dieses Problems mit den Rechnern 01, 03, 05 im Lehrerzimmern zurück zum Gerhard-Image.

@bau

Ist das kompatibel mit dem dort vorhandenen InfoSys-Image? Bei Bedarf bitte Maßnahmen ergreifen – die Kollegen brauchen funktionierende Infosys-Rechner.

[bau]

Es muss lediglich das neue InfoSys-Script (siehe #3088) auf die Rechner.
Am leichtesten geht das mit einem svn update in /usr/local/sbin, dann startet aber InfoSys auf Konsole 12.

[Rüdiger Kupper]

Ich kann das Problem an meinem Laptop zuhause reproduzieren, doch ich finde leider keine Lösung :-(.

Leider scheint auch keins der Foren, die ich oben verlinkt habe, wirklich genau dieses Problem zu beschreiben, wenn man genau hinschaut.

Mögliche Alternativlösung: Den windows-Nutzer per Autologin einloggen und ihn die VM im Vollbildmodus starten lassen. Dann wird seine Sitzung von gdm3 normal mitverwaltet.

[Rüdiger Kupper]

Puh! Das scheint zu funktionieren – jedenfalls hier an meinem Laptop zuhause.
Das muss ich morgen in der Schule ausprobieren.

[bau]

Test vor Ort:

• die TTYs werden von systemd verwaltet, in gdm3 gibt es keinerlei Einstellungsmöglichkeiten mehr!
• auf rechner-lz-06 getestet:

/etc/systemd/logind.conf

 NAutoVTs=1     # nur noch ein AutoVT (ist dann VT3)
 ReserveVT=3    # reserviere dafür VT3

/usr/local/sbin/kepler--lehrer--start-infosys-session

(sleep 5 ; xinit  /usr/local/sbin/infosys-session-windows-user -- :1 vt2) &
(sleep 5 ; chvt 3) &
(sleep 25 ; chvt 1) &

Das öffnet nach dem Start die infosys-session in VT2, ein VT-tty3 und geht zum gdm3 auf VT1. Danach verwaltet der gdm3 nur noch Konsolen nach der VT3 und macht auch keine weiteren VT-tty's mehr auf, die weiteren Konsolen bleiben schwarz (blinkender Cursor oben links)

Scheint mal zu funktionieren :-)

Status ist jetzt:

• altes Image an den Rechnern im LZ: 01 und 05
• neues Image mit dieser Methode: 02,03,04 und 06 (scheint überall zu tun)

[Rüdiger Kupper]

Super! Die Optionen habe ich auch gesehen, ich dachte nur nicht, dass man damit das Problem lösen kann! Funktioniert denn dann das Hin- und Herschalten mit eingeloggten Usern?

[Rüdiger Kupper]

Klappt leider immer noch nicht.

Ich versuche jetzt mal die oben erwähnte Alternativlösung:

• in /etc/gdm3/custom.conf:

  AutomaticLoginEnable = true
  AutomaticLogin = windows
  

• in /usr/local/sbin/infosys-session-windows-user:
  • ein paar Satusmeldungen für Syslog hinzugefügt
  • das Skript habe ich dann umbenannt in /usr/local/sbin/kepler--start-infosys.
• User windows darf dieses Skript mit Rootrechten starten:
  • Datei /etc/sudoers.d/windows-infosys anlegen und mit visudo bearbeiten:

    # infosys: windows user may execute infosys start script with root privileges
    #          on machines in 10.16.*.*
    
    Host_Alias    LEHRERNETZ = 10.16.0.0/16
    
    windows LEHRERNETZ=NOPASSWD: /usr/local/sbin/kepler--start-infosys
    

• /usr/local/sbin/kepler--lehrer-start-infosys-session:
  • nicht mehr benötigt, entfernt.
• in /etc/rc.local:
  • Aufruf von kepler--lehrer--start-infosys-session entfernt
• User windows erhält autostart-Skript in /home/windows/.config/autostart/infosys.desktop:

  [Desktop Entry]
  Type=Application
  Exec=/usr/bin/sudo /usr/local/sbin/kepler--start-infosys
  Terminal=true
  Hidden=false
  NoDisplay=false
  X-GNOME-Autostart-enabled=true
  Name[de_DE]=Infosys aktualisieren und starten
  Name=Infosys aktualisieren und starten
  Comment[de_DE]=Startet das Skript /usr/local/sbin/kepler--start-infosys mit Rootrechten.
  Comment=Startet das Skript /usr/local/sbin/kepler--start-infosys mit Rootrechten.
  
  
  

[Rüdiger Kupper]

Funktioniert. Infosys startet so übrigens wieder auf Konsole 2, die USB-Geschichte muss also wieder angepasst werden.

Damit die Rechner standardmäßig den gdm-Login-Bildschirm anzeigen, in /etc/rc.local hinzufügen:

logger -t KEPLER "rc.local: Schalte zurück auf VT 1, um Loginbildschirm zu zeigen."
(sleep 15 ; chvt 1) &

[Rüdiger Kupper]

Herrje, mir dem Autologin startet gdm3 gar keinen Loginbildschirm mehr. Laut Dokumentation muss man dazu den TimedLogin verwenden – der funktioniert aber bei uns nicht! Keine Ahnung, wieso das nun wieder. Das wäre der letzte Punkt. Argh.

[Rüdiger Kupper]

Neue Idee: Der windows-Nutzer kann aus dem Autostart-Skript heraus den gdm-Greeter starten. Dazu eignet sich der letzte Teil des hier beschriebenen Skripts:
​https://discourse.gnome.org/t/gdm-how-to-switch-user-in-command-line/917/4

[bau]

Vielleicht wäre eine Rehabilitierung des lightdm doch noch eine Alternative?
Dazu müsste man nur herausfinden, wo die gnome-shell ihren Lock-Screen aufruft und das anpassen.
Kann du das in irgendeinem Gnome-Forum mal nachfragen?

[Rüdiger Kupper]

Ja, das wäre auch noch eine Möglichkeit.

[Rüdiger Kupper]

Holldrio, das oben erwähnte Skript ist die Lösung. Da ist zwar ein kleiner Bug drin, der sich aber leicht beheben lässt.

So läuft es jetzt auf rechner-lz-06 und man kann stabil zwischen InfoSys und den Ubuntu-Sitzungen umschalten. InfoSys läuft auf Konsole 1, der Greeter auf Konsole 2 und die Sitzungen auf den Konsolen 3–6. Bitte mal testen!

Auf meinem Notebook (Ubuntu 19.10) braucht man das Skript übrigens nicht, da startet gdm3 den Greeter auch bei Autologin eines Users.

[Rüdiger Kupper]

Das Skript ist unter dem Namen switch-to-greeter ins svn eingechekt. Der windows-Nutzer braucht dann nur noch ein Autostartskript:

In ~windows/.config/autostart/switch-to-greeter.desktop:

[Desktop Entry]
Type=Application
Exec=/usr/local/sbin/switch-to-greeter
Terminal=false
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[de_DE]=Zum gdm3-Greeter schalten.
Name=Zum gdm3-Greeter schalten.
Comment[de_DE]=Schaltet zum gdm3-Greeter um und startet ihn bei Bedarf.
Comment=Schaltet zum gdm3-Greeter um und startet ihn bei Bedarf.

Der Konsole-Switch aus rc.local muss dann natürlich entfernt werden.