Freies tty finden

[MartinV]

Ich brauche eine Konsole bzw. ein tty, das gerade nicht in Gebrauch ist. Wie kann ich eines finden?

Auf Konsole funktioniert:

Code: Alles auswählen

fg-console --next-available

Aber in einem Terminal in X bekomme ich:

Code: Alles auswählen

Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.

Als root funktioniert es auch unter X! Ich brauche aber eine Lösung, die ohne root-Rechte funktioniert.
Kann ich den fehlenden "Dateideskriptor" für fgconsole irgendwie zur Verfügung stellen?
Oder gibt es eine ganz andere Möglichkeit?

[smutbert]

Der Benutzer müsste Mitglied in der Gruppe tty sein, der die Gerätedatei /dev/tty gehört.

[MartinV]

Tatsächlich, dann geht es auch unter X, danke für den Tip!
Seltsamerweise ging es auf Konsole auch ohne Mitgliedschaft in Gruppe tty.

Leider kann ich für meinen Anwendungszweck nicht erwarten, daß der Benutzer der Gruppe tty angehört, oder verlangen, daß er ihr hinzugefügt wird.

Geht es noch irgendwie anders? Zumal es auf Konsole auch ohne Gruppe tty geht?

[uname]

Oder gibt es eine ganz andere Möglichkeit?

Leider kenne ich deinen Anwendungsfall nicht.

Ich verwende gerne virtuelle Terminals mit screen oder tmux. Die und deren aktiven Anwendungen kann ich zwischen Konsole und X mitnehmen. Ich habe auch schon Anwendungen geschrieben, die Benutzer automatisch in Screen oder TMUX einsperren. Es kann aber sein, dass das für deinen Anwendungsfall nicht geeignet ist.

Vielleicht kannst du deinen Anwendungsfall und den Grund für ein echtes tty beschreiben.

[smutbert]

Ansonsten denke ich wäre es vielleicht möglich die Tatsache auszunutzen, dass die Gerätedatei eines Terminals dem Benutzer zugehörig gemacht wird, der dort angemeldet ist. Bei meiner wayland-Sitzung auf VT2 sieht das zum Besipiel gerade so aus

Code: Alles auswählen

$ ls -l /dev/tty*
crw-rw-rw- 1 root       tty     5,  0 Jun 21 11:05 /dev/tty
crw--w---- 1 root       tty     4,  0 Jun 21 11:05 /dev/tty0
crw--w---- 1 Debian-gdm tty     4,  1 Jun 21 11:05 /dev/tty1
crw--w---- 1 root       tty     4, 10 Jun 21 11:05 /dev/tty10
…
crw--w---- 1 root       tty     4, 19 Jun 21 11:05 /dev/tty19
crw--w---- 1 smutbert   tty     4,  2 Jun 21 11:05 /dev/tty2
crw--w---- 1 root       tty     4, 20 Jun 21 11:05 /dev/tty20
…

Das Problem dürfte sein, dass chvt, fgconsole,… gar nicht auf die Idee kommen »/dev/tty2« zu verwenden sondern der Reihe nach
- /proc/self/fd/0
- /dev/tty
- /dev/tty0
- /dev/vc/0
- /dev/console
- std{in,out,err}
versuchen [1], von denen in einem Terminalfenster unter X oder Wayland oder gar einem in Skript, das ohne Fenster oder VT läuft, keines auf »/dev/tty2« (oder eine andere Gerätedatei mit freundlicheren Berechtigungen und echten VT-Fähigkeiten) zeigt.

Auf einem echten VT dagegen zeigt bereits die erste Datei auf das tatsächlich aktive VT, das dem angemeldeten Benutzer gehört und mit dem dann alles funktioniert.


[1] https://superuser.com/questions/69807/w ... ot-under-x

[MartinV]

Vielleicht kannst du deinen Anwendungsfall und den Grund für ein echtes tty beschreiben.

Es geht um das Projekt https://github.com/mviereck/x11docker
Das Programm soll auf beliebigen Rechnern laufen können, ohne die Systemkonfiguration zu ändern oder root-Rechte haben zu müssen.

x11docker bietet u.a. die Option, neue X Server auf anderen ttys zu starten.
Das sind teilweise normale X Server, die ich auf tty1-tty12 unterbringe, teils "unsichtbare" mit Xdummy xserver-xorg-video-dummy, die mit xpra oder VNC sichtbar gemacht werden können.

Früher konnte man X ohne Angabe einer tty starten, und es hat sich selbst ein freies tty gesucht. Das geht seit debian stretch und/oder Xorg 1.19 nicht mehr, man muß explizit eine tty Nummer angeben mit der X option vt.

Ist das tty schon belegt mit einem X server, crasht der Start von X. Ist auf dem tty schon jemand eingeloggt (ohne X), wird X auf diesem tty gestartet, auch wenn da vielleicht schon etwas anderes läuft.

Zur Zeit behelfe ich mir mit "Wahrscheinlichkeitseinschätzungen", ohne eine saubere Lösung zu haben.

Ich habe einen Hinweis gefunden, warum fgconsole, chvt, openvt und Kollegen unter X nicht funktionieren (edit: der gleiche Link wie von @smutbert, danke!): https://superuser.com/questions/69807/w ... ot-under-x
Debian bug report: 522453
Es sind wohl Sicherheitsbedenken, um derentwillen der Zugriff auf die Konsole unter X nicht möglich gemacht wird.
Dort wird auch die Reihenfolge der Zugriffsversuche auf die Konsole gezeigt, die @smutbert gerade genannt hat.

Ansonsten denke ich wäre es vielleicht möglich die Tatsache auszunutzen, dass die Gerätedatei eines Terminals dem Benutzer zugehörig gemacht wird, der dort angemeldet ist.

Das habe ich auch schon einmal überlegt, bleibt aber sehr unsicher. Falls root auf einer Konsole angemeldet ist, kann ich das nicht erkennen. Im Augenblick nutze ich lightdm als Displaymanager, und das erscheint auch als root auf tty7.
------------
Ich bin gestern noch auf das Verzeichnis /sys/class/vc gestoßen, das vllt. helfen könnte. Es scheint die genutzten virtuellen Konsolen anzuzeigen. starte ich ein X auf z.B. tty10, erscheinen dort neue Einträge.
Wermutstropfen: Auch nach dem Ende von X bzw. der Freigabe von tty10 bleiben die Einträge in /sys/class/vc stehen.
Ich muß mal gucken, ob ich Dokumentation zu diesem Verzeichnis finde.

[smutbert]

Ok, bevor du geschrieben hast, wofür du das eigentlich willst, habe ich – angestachelt von der Tatsache, dass ich mich mit solchen Dingen eigentlich überhaupt nicht auskenne – noch etwas herumprobiert und eine entsetzlich häßliche Lösung gefunden, die aber erst einmal den Anschein erweckt zu funktionieren - vielleicht bringt sie dich ja auch auf eine vernünftigere Idee

Code: Alles auswählen

#!/bin/sh

for session_ID in $(loginctl --no-legend list-sessions | awk '{print $1}')
do
        loginctl_output=$(loginctl show-session ${session_ID})

        user_name=$(echo "${loginctl_output}" | sed -ne 's/^Name=//p')
        session_Type=$(echo "${loginctl_output}" | sed -ne 's/^Type=//p')
        session_Remote=$(echo "${loginctl_output}" | sed -ne 's/^Remote=//p')
        session_Active=$(echo "${loginctl_output}" | sed -ne 's/^Active=//p')
        session_TTY=$(echo "${loginctl_output}" | sed -ne 's/^TTY=//p')
        
        if test ${session_Active} = "yes" && test ${session_Remote} = "no"; then
                echo "aktive Sitzung: ${user_name} (${session_Type} auf /dev/${session_TTY})"
                echo "nächstes freies VT: $(fgconsole -n < /dev/${session_TTY})"
        fi
done

(wie man mit loginctl Sitzungen durchsucht hab ich schon gewusst, was mir gefehlt hat war die Idee der Eingabeumleitung beim Aufruf von fgconsole)

edit:
Es geht auch kürzer - zumindest unter wayland und gnome, andere DEs oder X kann ich grad nicht testen

Code: Alles auswählen

fgconsole -n < /dev/tty${XDG_VTNR}

edit nummer 2:
Auf einem System mit stretch und lightdm/xfce, das ich sonst von der Konfiguration aber nicht näher kenne, funktioniert es dagegen nicht. Hier bleiben alle nichtseriellen tty-Gerätedateien im Besitz von root. (Und X wird als root statt als angemeldeter Benutzer ausgeführt.)

[MartinV]

fgconsole -n < /dev/tty${XDG_VTNR}

Sehr elegant!

Auf einem System mit stretch und lightdm/xfce, das ich sonst von der Konfiguration aber nicht näher kenne, funktioniert es dagegen nicht. Hier bleiben alle nichtseriellen tty-Gerätedateien im Besitz von root.

Das kann ich leider auch bestätigen.

Der loginctl Ansatz ist auch sehr interessant. Auch wenn "fgconsole -n" nicht funktioniert, kann ich dennoch belegte ttys abfragen - zumindest die, auf denen ein Login erfolgt ist.
Ich stelle jedoch fest, daß von x11docker gestarteten X Server sessions sich nicht in loginctl wiederfinden lassen. Gleiches gilt für ttys, die ich z.B. mit openvt öffne. Diese zusätzlichen ttys sind also belegt, ohne daß loginctl eine Rückmeldung gibt.
Fazit: Mit loginctl kann ich einige belegte ttys feststellen, aber keine Aussage treffen, welche noch frei sind.