Run-Dialog/App-Launcher ohne Ergebnis - was passiert?

[Rotblitz]

An die Mods: Ich bin mir nicht sicher ob diese Thema eher in "FORTGESCHRITTENE THEMEN" gehört.

Ich habe mich gefragt, was im Hintergrund passiert, sollte man den App-Launcher (bei mir der in Fluxbox) via "ALT + F2" nutzen um ein Kommando auszuführen, welcher z.B. zur Autorisierung auffordert oder einfach eine reine Terminal-Ausgabe nutzen würde. Visuell gibt es ja keine Rückmeldung.

Ich denke mal, dass unterscheidet sich auch je nach Windowmanager, oder?

Als Beispiel:

Code: Alles auswählen

sudo virtualbox

oder

Code: Alles auswählen

top

Spawnen im Hintergrund Prozesse, die dann ewig auf eine Eingabe warten? Wären die dann z.B. via 'ps aux' als solche erkennbar oder als Child-Prozesse des Launchers zu finden.

[smutbert]

Die Prozesse werden zweifelsohne gestartet. Die Ausgaben werden, zB von systemd-journald, aufgezeichnet. Nehmen wir als Beispiel ein Skript, das irgendeinen Text ausgibt, weiterhin das Terminal, mit dem es verbunden ist und schließlich auf eine Eingabe wartet

Code: Alles auswählen

#!/bin/bash

echo "Hallo Welt!"
tty
select AUSWAHL in A B; do
    echo "Du hast ${AUSWAHL} ausgewählt"
done

In einem normalen Terminalfenster erhält man dann zB

Code: Alles auswählen

$ testskript.sh 
Hallo Welt!
/dev/pts/0
1) A
2) B
[?]: 1
Du hast A ausgewählt
[?]: q
Du hast  ausgewählt
[?]: ^C

bis man das Skript mit <Ctrl>+<C> abbricht. Wenn ich dieses Skript nun mittels <Alt>+<F2> starte… passiert augenscheinlich gar nichts, aber im Systemlog finde ich (hier wie man sieht unter Gnome)

Code: Alles auswählen

# journalctl -p 7
…
Jun 14 12:27:42 pc gnome-session[832]: Hallo Welt!
Jun 14 12:27:42 pc gnome-session[832]: kein Ausgabegerät
Jun 14 12:27:42 pc gnome-session[832]: 1) A
Jun 14 12:27:42 pc gnome-session[832]: 2) B
Jun 14 12:27:42 pc gnome-session[832]: #?
…

Vermutlich merkt das Skript aber, ähnlich wie es tty mit "kein Ausgabegerät" merkt, das es mit keinem Terminal verbunden ist, dass es vergeblich warten würde. Das ist zumindest die einzige Erklärung, die mir einfällt, warum ich mit ps den zugehörigen Prozess nicht finde.

Andere Programme mögen sich etwas anders verhalten und tatsächlich bis in alle Ewigkeit vergeblich auf eine Eingabe warten , aber ich denke das Verhalten wird auch mit anderen Desktopumgebungen oder Fenstermanagern ähnlich sein.

Vor bzw. ohne systemd wären die Meldungen aber wohl in ~/.xsession-errors gelandet.

Wenn ich noch ein sleep einbaue, damit ich genug Zeit habe mir die Hierarchie anzusehen, kommt das hier heraus

Code: Alles auswählen

systemd─┬─…
        ├─gdm3─┬─Xorg───3*[{Xorg}]
        │      ├─gdm-session-wor─┬─x-session-manag─┬─…
        │      │                 │                 ├─gnome-shell─┬─…
        │      │                 │                 │             ├─testskript.sh───sleep
        …      …                 …                 …             …