Prozess wieder in den Vordergrund holen

[Alexander Goetzenstein]

Hallo,
auf meinem NAS habe ich, per ssh verbunden, ein Script gestartet, das
voraussichtlich etliche Stunden, wenn nicht mehrere Tage laufen wird. Da
ich nicht die ganze Zeit die ssh-Sitzung aufrecht erhalten kann, habe
ich es mit & in den Hintergrund geschickt. Nun möchte ich von Zeit zu
Zeit nachsehen, was es so tut und wie weit es ist und möchte es nach
erneuter Verbindung mit ssh wieder in den Vordergrund holen. Wie mache
ich das, wenn screen nicht existiert?



--
Gruß
Alex

[Ulli Horlacher]

screen oder tmux installieren.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Alexander Goetzenstein]

Hallo,

Am 14.08.22 um 14:14 schrieb Ulli Horlacher:

> Alexander Goetzenstein <alexander_g...@web.de> wrote:
>> Hallo,
>> auf meinem NAS habe ich, per ssh verbunden, ein Script gestartet, das
>> voraussichtlich etliche Stunden, wenn nicht mehrere Tage laufen wird. Da
>> ich nicht die ganze Zeit die ssh-Sitzung aufrecht erhalten kann, habe
>> ich es mit & in den Hintergrund geschickt. Nun möchte ich von Zeit zu
>> Zeit nachsehen, was es so tut und wie weit es ist und möchte es nach
>> erneuter Verbindung mit ssh wieder in den Vordergrund holen. Wie mache
>> ich das, wenn screen nicht existiert?
>
> screen oder tmux installieren.

anders geht es nicht?



--
Gruß
Alex

[Ulli Horlacher]

Vielleicht gibts noch Programme mit aehnlicher Funktionalitaet, aber die
musst du auch erst installieren.

Was spricht gegen screen?

Verwende ich seit ueber 30 Jahren, problemlos.

[Alexander Goetzenstein]

Hallo,

Am 14.08.22 um 14:48 schrieb Ulli Horlacher:
> Was spricht gegen screen?

dass ich es nicht installieren kann, weil es das für das Gerät nicht gibt.


--
Gruß
Alex

[Helmut Waitzmann]

Alexander Goetzenstein <alexander_g...@web.de>:

Es geht nicht ohne Screen oder einen ähnlichen Terminalserver.  Wenn
du die ssh‐Sitzung beendest, beendest du damit den Sitzungsführer
der Prozesse.  Dann verschwindet auch das Steuer‐Terminal der
Sitzung.  Ohne das Terminal gibt es auch keinen Vordergrund mehr.

[Thomas Dorner]

Sehr schön beschrieben!

Für Alexander, die einzige Alternative die mir noch einfällt, ist sich
per strace oder ähnlichem dranzuhängen, falls Du anhand von
Systemaufrufen des Programms/Skripts etwas über den Fortschritt
feststellen kannst. Hmm, bei einem Skript könnten es natürlich auch mit
ps sichtbare Unterprozesse sein.
Ersteres habe ich schon mal verwendet, um einen länger laufenden
rekursiven diff zu überwachen (trace auf alle "open").

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Alexander Goetzenstein]

Hallo,

Am 15.08.22 um 01:32 schrieb Andreas Kohlbach:
>
> Bei vielen Prozessen geht
>
> fg
>
> Bei ssh habe ich aber meine Zweifel.
>
> Sollte es doch gehen, kann es mit
>
> bg
>
> wieder im Hintergrund arbeiten.
>
> Mit
>
> jobs kannst Du rausbekommen, welche Prozesse im Hintergrund sind. Und mit
>
> fg 2
>
> vielleicht den 2. wieder in der Vordergrund holen.

das funktioniert nur, solange man die Sitzung nicht verlässt.


--
Gruß
Alex

[Dr Eberhard Lisse]

Nohup?

mfg, el

To email me replace 'nospam' with 'el'

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Mon, 15 Aug 2022 11:47:04 +0200, Alexander Goetzenstein wrote:
>>
>> Am 15.08.22 um 01:32 schrieb Andreas Kohlbach:
>>>
>>> Bei vielen Prozessen geht
>>>
>>> fg
>>>
>>> Bei ssh habe ich aber meine Zweifel.
>

>[...]

>
>> das funktioniert nur, solange man die Sitzung nicht verlässt.
>>
>

>Hatte ich mir [bei ssh] auch gedacht. Bei anderen (ich mache das
>oft im Text-Browser lynx) geht es aber.

Mensch, Andreas!  Dein Hinweis ist etwa so schlau wie der in der
folgenden Situation:

«Ich bin letztens mit dem Motorrad gefahren und im Starkregen
sehr nass geworden.  Was kann ich anziehen, um trocken zu
bleiben?» – «Ich habe einfach das Schiebedach zu gemacht.  Da
bleibe ich trocken.  Besondere Kleidung brauche ich nicht.»

Wenn du doch nur etwas sorgfältiger im Lesen wärst!  Statt dessen
unterschlägst du einen Teil der Voraussetzungen des geschilderten
Problems und schlägst demnach eine nicht funktionierende Lösung
vor.  Dadurch dreht die Diskussion munter eine weitere Runde, bei
der schließlich niemand mehr weiß, worum es eigentlich geht; und
weder Alexander noch denen, die durch Mitlesen und ‐Denken etwas
dazulernen wollen, ist geholfen.

Alexander schreibt doch ausdrücklich (du must es nur noch
lesen!):

>> das funktioniert nur, solange man die Sitzung nicht verlässt.
>>

Im OP schreibt er:

| Nun möchte ich von Zeit zu Zeit nachsehen, was es so tut
| und wie weit es ist und möchte es nach erneuter Verbindung
| mit ssh wieder in den Vordergrund holen.

«Erneute Verbindung mit ssh» meint zwangsläufig, dass die vorige
«ssh»‐Verbindung beendet worden ist, denn sonst wäre es keine
erneute Verbindung.  Dabei wird natürlich auch das auf dem
entfernten Rechner von «ssh» aufgebaute Pseudoterminal beendet. 
Das ist aber das controlling terminal für die, auf dem entfernten
Rechner laufende, Sitzung.  Dadurch beendet sich der
Sitzungsführer (vermutlich der von «ssh» gestartete Shell) auf
dem entfernten Rechner, und die in ihr laufende Prozessgruppe
verwaist.

Sobald man einen Sitzungsführer beendet, verwaisen die sich in
der Sitzung befindenden Prozessgruppen.  Das Terminal wird dann
ebenfalls aufgelöst, und die Prozessgruppen haben kein
Steuerterminal (controlling terminal) und keinen Sitzungsführer
mehr.

Das Steuerterminal ist das Terminal, in dessen Vordergrund ein
Prozess laufen kann.  Es ist das Terminal, in dem man Control-Z
tippen kann, um einen im Vordergrund laufenden Prozess zu
stoppen.  Ist das Steuerterminal eines Prozesses verschwunden,
gibt es kein Terminal mehr, in dessen Vordergrund der Prozess
geholt werden kann.


Probiere folgendes aus:


Öffne einen Terminalemulator (beispielsweise ein «xterm»,
«gnome-terminal», …), in dem ein Shell läuft.


Tippe dort das folgende Kommando ein:


sleep -- 900 &

(«sleep» läuft, also, wartet, 900 Sekunden lang, ehe es sich
beendet – genug, um das folgende zu beobachten:)


Tippe das folgende Kommando ein:


ps -o ppid -o tty -o tpgid -o sid -o pgid -o pid \
-o stat -o stime -o args

Betrachte insbesondere die Spalten «TT» (das controlling
terminal), «SID» (die Sitzungsnummer), «PGID» (die
Prozessgruppennummer) und «STAT» (der Prozesszustand).

Bemerke, dass der Sitzungsführer der Prozess ist, bei dem in den
Spalten «SID», «PGID» und «PID» dieselbe Zahl steht.  Notiere dir
diese Zahl.  Bemerke, das in der Spalte «STAT» (u. a.) beim
Sitzungsführer ein «s» steht.

Schau die Zeile mit dem Programm «ps» an:  In der Spalte «TPGID»
steht die Prozessgruppennummer der Prozessgruppe, die im
Augenblick im Vordergrund des Terminals ist.  Bemerke, dass das
dieselbe Zahl ist, wie die in der Spalte «PGID».  der Spalte
«STAT» steht bei den Prozessen der Vordergrundprozessgruppe
(u. a.) ein «+».

Notiere dir das controlling terminal (Spalte «TT»).  Beende den
Shell.

In einem anderen Shell (in einem anderen Terminal) starte das
folgende Kommando, wobei du statt des Fragezeichens die notierte
Nummer der Spalte «SID» hinschreibst:

ps -o ppid -o tty -o tpgid -o sid -o pgid -o pid \
-o stat -o stime -o args -s ?

Betrachte in der Ausgabe die Spalte «TT», die das controlling
terminal nennt.  Bemerke, dass dort nicht mehr das steht, was du
zuvor notiert hattest.  Bemerke, dass es keinen Prozess mehr
gibt, der der Sitzungsführer ist (gemäß der oben erwähnten
Kennzeichen in der Tabelle).

Außerdem:  Wenn die Prozesse der verwaisten Sitzung weiterhin
versuchen, Ausgaben auf ihr ehemaliges Controlling Terminal (das
es nicht mehr gibt) zu machen, werden sie einen Ausgabefehler
erhalten.  Solange ihnen also niemand mitteilt, wohin statt
dessen Ausgaben jetzt zu machen wären, kommt man an diese
gescheiterten Ausgaben nicht heran und Alexanders Wunsch

| Nun möchte ich von Zeit zu Zeit nachsehen, was es so tut
| und wie weit es ist

ist nicht erfüllbar, denn diese Prozesse haben keine Möglichkeit
einprogrammiert, mit der man ihnen mitteilen könnte, wohin sie
ihre Ausgaben ab jetzt schicken sollen.
--
Hat man erst verstanden, wie Unix funktioniert, ist auch
das Shell-Handbuch kein Buch mit sieben Siegeln mehr.

[Arno Welzel]

Alexander Goetzenstein, 2022-08-14 15:36:

Welches Gerät?

Für Synology gibt es tmux:

<https://www.martv.de/index.php/tmux-auf-synology>

<https://synocommunity.com/packages>


--
Arno Welzel
https://arnowelzel.de

[Marco Moock]

Am Sonntag, 14. August 2022, um 14:12:40 Uhr schrieb Alexander
Goetzenstein:

Was man mit & in den Hintergrund gebracht hat, kann man mit fg
zurückholen.
Mit jobs siehst du alle Hintergrundprozesse.

[Christian Weisgerber]

On 2022-08-16, Andreas Kohlbach <a...@spamfence.net> wrote:

> Eben habe ich Zugriff auf einen entfernten Rechner.
>
> ssh 1.2.3.4 &
>
> druckt erst mal nur seine IP. Irgendwas anderes als "fg" bringt
>
> [1]+ Stopped ssh 1.2.3.4
>
> erst ein "fg" started die Session dann auch.

ssh läuft halt im Hintergrund bis zum ersten TTY-Zugriff und wird
dann gestoppt. Da kann z.B. Pubkey-Authentisierung schon abgeschlossen
sein. Holt man den Prozess in den Vordergrund, gehts weiter.

> Damit ist fg für SSH
> *ungeeignet*. Schon, weil man (natürlich) mit CRTL-z die Session nicht in
> den Hintergrund bringen kann.

Man kann eine interaktive SSH-Sitzung mit ~^Z in den Hintergrund
legen. Siehe Abschnitt ESCAPE CHARACTERS.

> Btw. mir fällt auf, dass eine mit "&" gestartete SSH-Session keinen
> Feedback (Anzeige von dem, was ich tippe) bringt.

Dunkel ist deiner Rede Sinn.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Rupert Haselbeck]

Marco Moock schrieb:

> Alexander Goetzenstein:
>> auf meinem NAS habe ich, per ssh verbunden, ein Script gestartet, das
>> voraussichtlich etliche Stunden, wenn nicht mehrere Tage laufen wird.
>> Da ich nicht die ganze Zeit die ssh-Sitzung aufrecht erhalten kann,
>> habe ich es mit & in den Hintergrund geschickt. Nun möchte ich von
>> Zeit zu Zeit nachsehen, was es so tut und wie weit es ist und möchte
>> es nach erneuter Verbindung mit ssh wieder in den Vordergrund holen.
>> Wie mache ich das, wenn screen nicht existiert?
>
> Was man mit & in den Hintergrund gebracht hat, kann man mit fg
> zurückholen.

Nein, das geht nicht, da die ssh-Verbindung, und damit auch etwaige
früher in den Hintergrund geschobene Prozesse, inzwischen beendet wurde.
Das wurde ihm hier - zutreffend - schon ausführlich erklärt. Die
Problemlösung heisst "screen" (oder etwas funktionsgleiches) installieren...

> Mit jobs siehst du alle Hintergrundprozesse.

Aber nur, solange sie noch existieren

MfG
Rupert

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:
>On Mon, 15 Aug 2022 21:32:46 +0200, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:

>>
>> Alexander schreibt doch ausdrücklich (du must es nur noch
>> lesen!):
>>

>> Im OP schreibt er:
>>
>>
>> | Nun möchte ich von Zeit zu Zeit nachsehen, was es so tut
>> | und wie weit es ist und möchte es nach erneuter Verbindung
>> | mit ssh wieder in den Vordergrund holen.
>>
>> «Erneute Verbindung mit ssh» meint zwangsläufig, dass die vorige
>> «ssh»‐Verbindung beendet worden ist, denn sonst wäre es keine
>> erneute Verbindung.  Dabei wird natürlich auch das auf dem
>> entfernten Rechner von «ssh» aufgebaute Pseudoterminal beendet. 
>

>Ich bin von einer Missdeutung ausgegangen und nahm an, eine laufende
>(nicht beendete) SSH-Session war gemeint.

Gut, dann ist das ja jetzt geklärt.

>Eben habe ich Zugriff auf einen entfernten Rechner.
>
>
>ssh 1.2.3.4 &
>
>druckt erst mal nur seine IP. Irgendwas anderes als "fg" bringt
>
>
>[1]+ Stopped ssh 1.2.3.4
>
>erst ein "fg" started die Session dann auch.
>

«ssh» ist bereits gestartet, ist aber gestoppt worden, weil es
versucht hat, vom Terminal zu lesen (beispielsweise ein Passwort
oder Kommandos für den auf dem Rechner «1.2.3.4» gestarteten Shell),
während es im Hintergrund ist.

Das ist nichts ungewöhnliches.  Probiere mal das folgende Kommando
aus:

( printf '%s\n' 'Hello, world!' && sleep -- 1 && read -- v ) &

Das reagiert ebenso.  Wenn du es dann mit dem Shell‐Kommando «fg» in
den Vordergrund holst, will es eine Textzeile lesen.  Drücke die
Return‐Taste, damit es eine bekommt und sich beendet.

>Damit ist fg für SSH *ungeeignet*.
>

Nein, das ist es nicht.

>Schon, weil man (natürlich) mit CRTL-z die Session nicht in den
>Hintergrund bringen kann.

Statt nur Control-Z zu tippen, probiere mal, erst ein Tilde‐Zeichen
(«~») und dann Control-Z zu tippen.  Im Abschnitt «ESCAPE
CHARACTERS» im Handbuch «ssh(1)» steht etwas dazu.

>Btw. mir fällt auf, dass eine mit "&" gestartete SSH-Session keinen
>Feedback (Anzeige von dem, was ich tippe) bringt.

Das kann eine Unzulänglichkeit oder ein Programmfehler von «ssh»
sein.  Als Abhilfe starte «ssh» im Vordergrund und stoppe es erst
dann.

[Helmut Waitzmann]

Marco Moock <mo...@posteo.de>:

Das Problem dabei ist, dass man «fg» in genau dem Shell eintippen
muss, in dem man zuvor auch das Kommando im Hintergrund laufen
gelassen hatte.  Der Shell, in dem Alexander das gemacht hatte, ist
aber inzwischen beendet.  Das ist nur erkennbar an Alexanders
Formulierung «nach erneuter Verbindung mit ssh», aus der man
schließen muss, dass die ursprüngliche Verbindung mit «ssh» nicht
mehr besteht.

[Andreas Kohlbach]

On Tue, 16 Aug 2022 12:35:57 -0000 (UTC), Christian Weisgerber wrote:
>
> On 2022-08-16, Andreas Kohlbach <a...@spamfence.net> wrote:
>
>> Damit ist fg für SSH
>> *ungeeignet*. Schon, weil man (natürlich) mit CRTL-z die Session nicht in
>> den Hintergrund bringen kann.
>
> Man kann eine interaktive SSH-Sitzung mit ~^Z in den Hintergrund
> legen. Siehe Abschnitt ESCAPE CHARACTERS.

Ah. Muss man wohl erst einrichten.

>> Btw. mir fällt auf, dass eine mit "&" gestartete SSH-Session keinen
>> Feedback (Anzeige von dem, was ich tippe) bringt.
>
> Dunkel ist deiner Rede Sinn.

Normal sehe ich auf der TTY den Text beim Eintippen; auch in einer
SSH-Session. Starte ich "ssh 1.2.3.4 &" wird kein Text "ge-echoed". Die
Augabe von Befehlen allerdings schon.

Das ich aber keine ssh & mache, ist das unwichtig, als dass das einer
Erklärung bedürfte. Wunderte mich nur.
--
Andreas

[Christian Weisgerber]

On 2022-08-16, Andreas Kohlbach <a...@spamfence.net> wrote:

>> Man kann eine interaktive SSH-Sitzung mit ~^Z in den Hintergrund
>> legen. Siehe Abschnitt ESCAPE CHARACTERS.
>
> Ah. Muss man wohl erst einrichten.

Nein, braucht man nicht.

> Normal sehe ich auf der TTY den Text beim Eintippen; auch in einer
> SSH-Session. Starte ich "ssh 1.2.3.4 &" wird kein Text "ge-echoed". Die
> Augabe von Befehlen allerdings schon.

Nein, das passiert nicht.

[Helmut Waitzmann]

Christian Weisgerber <na...@mips.inka.de>:

>On 2022-08-16, Andreas Kohlbach <a...@spamfence.net> wrote:
>
>> Normal sehe ich auf der TTY den Text beim Eintippen; auch in
>> einer SSH-Session. Starte ich "ssh 1.2.3.4 &" wird kein Text
>> "ge-echoed". Die Augabe von Befehlen allerdings schon.
>
>Nein, das passiert nicht.
>

Also bei mir (Debian 10) passiert das schon:  Ich starte einen
interaktiven Shell auf dem entfernten Rechner, ohne ein Passwort
eintippen zu müssen, weil «ssh» mit Usekeys konfiguriert ist:

ssh -t -- account@rechner &

Der Job läuft los und stoppt.  Ich kann ihn mit dem Kommando «fg» in
den Vordergrund holen und dann beispielsweise ein Kommando, etwa

stty

blind eintippen, das heißt, ich sehe nicht, was ich tippe.  Wenn ich
das Kommando abschicke, erhalte ich die Ausgabe

speed 38400 baud; line = 0;
lnext = <undef>; discard = <undef>; min = 1; time 0;
-brkint -icrnl -imaxbel iutf8
-icanon -echo

und den nächsten Prompt vom Shell auf «rechner».  «-echo» in der
Ausgabe von «stty» auf dem entfernten Rechner erklärt das Verhalten.


Tippe ich (immer noch blind) das Kommando


stty echo

ein und lasse es laufen, bekomme ich im weiteren, wie gewünscht, zu
sehen, was ich eintippe.


Starte ich jedoch


ssh -t -- account@rechner

und tippe anschließend (sichtbar) das Kommando


stty

ein und lasse es laufen, erhalte ich die Ausgabe


speed 38400 baud; line = 0;
-brkint -imaxbel iutf8

=> Echo ist nicht abgeschaltet.

[Sieghard Schicktanz]

Hallo Andreas Kohlbach,

Du schriebst am Tue, 16 Aug 2022 15:31:11 -0400:

> Normal sehe ich auf der TTY den Text beim Eintippen; auch in einer
> SSH-Session. Starte ich "ssh 1.2.3.4 &" wird kein Text "ge-echoed".
> Die Augabe von Befehlen allerdings schon.

Das siehst Du allerdings reichlich, na, sag'nmermal, verzerrt.
Mit dem "&" am Ende wird Deine ssh-Sitzung bereits in den Hintergrund
getreten, wenn sie noch nichtmal offen ist. Sobald die versucht,
wasauszugeben, und keinen Zugriff auf das Terminal mehr bekommt (z.B.
weil Du das mit was anderen in Beschlag genommen hast), wird sie
gestoppt. Was Du _nach_ dem Start der ssh-Verbindung im Hintergrund
eintippst, geht nicht (mehr) an diese, sondern an die Shell im
Vordergrund, die dann ganz normal darauf reagiert.
An die ssh-Shell kommst Du erst dann wieder 'ran, wenn Du die per "fg"
in den Vordergrund zurückholst; dann kriegt die Deine Eingaben und kann
sich auch (wieder) bemerkbar machen.

> Das ich aber keine ssh & mache, ist das unwichtig, als dass das einer
> Erklärung bedürfte. Wunderte mich nur.

Es ist IMHO schon wichtig, daß man weiß, wie seine Werkzeuge
funktionieren. Damit könnten wohl oft Unfälle, auch schwere, vermieden
werden. Sich wundern hilft halt wenig für das Verständnis, wenn es
nur dabei bleibt.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Andreas Kohlbach]

On Wed, 17 Aug 2022 00:45:55 +0200, Sieghard Schicktanz wrote:
>
> Hallo Andreas Kohlbach,
>
> Du schriebst am Tue, 16 Aug 2022 15:31:11 -0400:
>
>> Normal sehe ich auf der TTY den Text beim Eintippen; auch in einer
>> SSH-Session. Starte ich "ssh 1.2.3.4 &" wird kein Text "ge-echoed".
>> Die Augabe von Befehlen allerdings schon.
>
> Das siehst Du allerdings reichlich, na, sag'nmermal, verzerrt.

Nein, siehe was Helmut gerade bestätigte.

> Mit dem "&" am Ende wird Deine ssh-Sitzung bereits in den Hintergrund
> getreten, wenn sie noch nichtmal offen ist. Sobald die versucht,
> wasauszugeben, und keinen Zugriff auf das Terminal mehr bekommt (z.B.
> weil Du das mit was anderen in Beschlag genommen hast), wird sie
> gestoppt. Was Du _nach_ dem Start der ssh-Verbindung im Hintergrund
> eintippst, geht nicht (mehr) an diese,

Soweit klar.

> sondern an die Shell im Vordergrund, die dann ganz normal darauf
> reagiert.
>
> An die ssh-Shell kommst Du erst dann wieder 'ran, wenn Du die per "fg"
> in den Vordergrund zurückholst; dann kriegt die Deine Eingaben und kann
> sich auch (wieder) bemerkbar machen.

Nein, eben nicht. Es erfolgt zumindest bei mir (und offenbar Helmut)
keine Ausgabe des gerade Getippten, obwohl die SSH-Session im
*Vordergrund* ist.

>> Das ich aber keine ssh & mache, ist das unwichtig, als dass das einer
>> Erklärung bedürfte. Wunderte mich nur.
>
> Es ist IMHO schon wichtig, daß man weiß, wie seine Werkzeuge
> funktionieren. Damit könnten wohl oft Unfälle, auch schwere, vermieden
> werden. Sich wundern hilft halt wenig für das Verständnis, wenn es
> nur dabei bleibt.

Es ist (mir) unwichtig. Ich muss auch nicht wissen, warum die Banane
krumm ist (obwohl es sicher im Netz genug antworten gibt), um sie zu
essen. Ich erwarte (auch bei "ssh ... &" nicht, weil das eh nicht
vorkommt) keine Unfälle. Außer wenn ich die Schale auf den Bürgersteig
werfen sollte. Aber auch das mache ich nicht.
--
Andreas

[Helmut Waitzmann]

Helmut Waitzmann <nn.th...@xoxy.net>:

>Starte ich jedoch
>
>
> ssh -t -- account@rechner
>
>und tippe anschließend (sichtbar) das Kommando
>
>
> stty
>
>ein und lasse es laufen, erhalte ich die Ausgabe
>
>
> speed 38400 baud; line = 0;
> -brkint -imaxbel iutf8
>
>=> Echo ist nicht abgeschaltet.
>

Um den Vergleich zu vervollständigen:  Wenn ich den «ssh»‐Aufruf im
Vordergrund gemacht habe, kann ich ihn stoppen (indem ich eine
Tilde, gefolgt von Control‐Z eintippe).  Wenn ich ihn dann später
mit dem (lokalen) Kommando «fg» wiederaufnehme, funktioniert das
Eingabeecho weiterhin.  Auch wenn ich ihn nach dem Stoppen mit dem
Kommando «bg» in den Hintergrund schicke (wo er sofort gestoppt
wird) und später wieder mit «fg» in den Vordergrund hole,
funktioniert das Eingabeecho weiterhin.

[Christian Weisgerber]

On 2022-08-17, Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> ssh -t -- account@rechner &
>
> Der Job läuft los und stoppt.  Ich kann ihn mit dem Kommando «fg» in
> den Vordergrund holen und dann beispielsweise ein Kommando, etwa
>
> stty
>
> blind eintippen, das heißt, ich sehe nicht, was ich tippe.  Wenn ich
> das Kommando abschicke, erhalte ich die Ausgabe

Ja, ich kann das jetzt reproduzieren. Dazu braucht man die passende
Login-Shell wie bash. Mit tcsh dagegen tritt der Effekt gar nicht
auf, pdksh verdeckt das Problem.

Ich werde mir das mal genauer anschauen.

> speed 38400 baud; line = 0;
> lnext = <undef>; discard = <undef>; min = 1; time 0;
> -brkint -icrnl -imaxbel iutf8
> -icanon -echo
>
> und den nächsten Prompt vom Shell auf «rechner».  «-echo» in der
> Ausgabe von «stty» auf dem entfernten Rechner erklärt das Verhalten.

Nur zufällig.

Praktisch alle Shells im interaktiven Betrieb
(1) sichern die TTY-Einstellungen,
(2) setzen eigene Einstellungen, während sie am Prompt Eingaben
entgegennehmen,
(3) schalten vor der Befehlsausführung auf die gesichterten
Einstellungen zurück,
(4) nachdem der Befehl beendet ist, gehe zu (1).

Das heißt, dass dir stty die Einstellungen bei der Befehlsausführung
zeigt, aber _nicht_ die am Shellprompt. Um letztere zu sehen, muss
man von einem separaten Login mit stty jenes TTY abfragen, wo die
Shell gerade mit dem Prompt wartet. Und das beobachtete Problem war
ja das fehlende Echo am Prompt.

Die tatsächlichen TTY-Einstellungen am Prompt sind hier aber auch
nicht sehr hilfreich, weil z.B. bash grundsätzlich echo abschaltet
und Zeichen selbst ausgibt. Dass "stty -echo" dann bash überhaupt
beeinflusst, liegt offenkundig daran, dass bash diese Einstellung
auswertet und das eigene Verhalten anpasst; pdksh z.B. tut das nicht
und zeigt die Eingabe immer an.

Beispiel:

$ stty -a # Einstellungen während Befehlsausführung
speed 38400 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
-brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab3 -onocr -onlret
cflags: cread cs8 parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>; eol2 = ^@;
erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
$ tty
/dev/pts/6

Anderes Terminal:

$ stty -a </dev/pts/6 # Einstellungen am Prompt
speed 38400 baud; 24 rows; 80 columns;
lflags: -icanon isig iexten -echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip -icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
-brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab3 -onocr -onlret
cflags: cread cs8 parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf rtsdtr
cchars: discard = <undef>; dsusp = <undef>; eof = ^D; eol = <undef>;
eol2 = ^@; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = <undef>; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

[Helmut Waitzmann]

Christian Weisgerber <na...@mips.inka.de>:

>On 2022-08-17, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>
>> ssh -t -- account@rechner &
>>
>> Der Job läuft los und stoppt.  Ich kann ihn mit dem Kommando «fg»
>> in den Vordergrund holen und dann beispielsweise ein Kommando,
>> etwa
>>
>> stty
>>
>> blind eintippen, das heißt, ich sehe nicht, was ich tippe.  Wenn
>> ich das Kommando abschicke, erhalte ich die Ausgabe
>
>Ja, ich kann das jetzt reproduzieren. Dazu braucht man die passende
>Login-Shell wie bash. Mit tcsh dagegen tritt der Effekt gar nicht
>auf, pdksh verdeckt das Problem.
>
>Ich werde mir das mal genauer anschauen.
>
>
>> speed 38400 baud; line = 0;
>> lnext = <undef>; discard = <undef>; min = 1; time 0;
>> -brkint -icrnl -imaxbel iutf8
>> -icanon -echo
>>
>> und den nächsten Prompt vom Shell auf «rechner».  «-echo» in der
>> Ausgabe von «stty» auf dem entfernten Rechner erklärt das
>> Verhalten.
>
>Nur zufällig.
>

Nicht ganz zufällig (sondern mit Absicht, aber nicht ursächlich). 
Es ist richtig, was du im folgenden beschreibst:

>Praktisch alle Shells im interaktiven Betrieb
>(1) sichern die TTY-Einstellungen,
>(2) setzen eigene Einstellungen, während sie am Prompt Eingaben
> entgegennehmen,
>(3) schalten vor der Befehlsausführung auf die gesichterten
> Einstellungen zurück,
>(4) nachdem der Befehl beendet ist, gehe zu (1).
>
>Das heißt, dass dir stty die Einstellungen bei der
>Befehlsausführung zeigt, aber _nicht_ die am Shellprompt.

Ja, das ist richtig.  Aber Shells tun gut daran, bei der Abarbeitung
von (2) und anschließender Verwendung des Terminals bei der
Entgegennahme von Eingaben am Prompt sich an (1) zu orientieren: 
Beispielsweise sollten sie gerade die Echo‐Einstellungen von (1)
beachten:  Finden sie das Echo der kanonischen Terminal‐Betriebsart
abgeschaltet vor, sollten sie auch in ihrer Emulation (2) kein Echo
simulieren, weil sie davon ausgehen sollten, dass der Anwender
tatsächlich kein Echo haben will (beispielsweise, damit niemand, der
ihm über die Schulter schaut, sieht, was er gerade (an
Shell‐Kommandos) eintippt).

>Um letztere zu sehen, muss man von einem separaten Login mit stty
>jenes TTY abfragen, wo die Shell gerade mit dem Prompt wartet. Und
>das beobachtete Problem war ja das fehlende Echo am Prompt.

Ja.  Der jeweilige Aufruf von «stty» auf dem entfernten Rechner gibt
nur einen Hinweis, dass der Shell in beiden Fällen verschiedener
Meinung darüber ist, welche Echo‐Einstellungen das Terminal haben
sollte, solang vom Shell gestartete Programme (hier: «stty») laufen.

Bleibt also die Frage, warum der Shell auf dem entfernten Rechner
der Meinung ist, unterschiedliche Terminal‐Einstellungen vornehmen
zu müssen, wenn es Programme (hier: «stty» startet), und sich
unterschiedlich verhalten zu sollen, jeweils abhängig davon, ob
«ssh» im Vordergrund oder im Hintergrund gestartet wurde:  Wurde
«ssh» im Vordergrund gestartet, entscheidet es sich dafür, mit
eingeschaltetem Echo zu arbeiten bzw. eingetippte Zeichen zu
spiegeln, wurde es hingegen im Hintergrund gestartet, entscheidet es
sich dafür, es bleiben zu lassen.

Die Antwort würde ich in der folgenden Richtung suchen:  Was
erhalten Programme, die im Hintergrund laufen, an Information vom
Terminal, wenn sie – wie «stty» – nach Terminal‐Einstellungen
fragen?

Dazu starte ich jetzt einfach mal ohne «ssh» lokal aus einem «bash»
heraus:

stty -a &

Das liefert mir auf Debian 10 unter anderem «-echo» (also kein
Echo), während

stty -a

«echo» (also mit Echo) liefert.


Wiederhole ich den Versuch aus einem «dash» heraus, erhalte ich in
beiden Fällen «echo»!

Da scheint also der Hase im Pfeffer zu liegen:  «bash» startet
Kommandos im Hintergrund mit abgeschaltetem Echo auch dann, wenn das
Echo an sich (als) eingeschaltet (zu betrachten) ist.

Bis jetzt (also, ohne weitere Gründe zu kennen oder Folgen
abzuschätzen) betrachte ich das als Fehler:  Ich meine bisher, das
Kommando

ein Kommando

sollte mit dem Kommando


{ ein Kommando & } ; fg

so äquivalent wie irgend möglich sein.


Die Gegenprobe, aus einem «dash» heraus «ssh» im Hintergrund zu
starten und das dann gestoppte «ssh» nachträglich in den Vordergrund
zu holen, liefert in der Tat ebenfalls eingeschaltetes Echo beim
Start des Kommandos «stty -a» auf dem entfernten Rechner und der
«bash» auf dem entfernten Rechner spiegelt die eingetippten Zeichen
zurück.

>Die tatsächlichen TTY-Einstellungen am Prompt sind hier aber auch
>nicht sehr hilfreich, weil z.B. bash grundsätzlich echo abschaltet
>und Zeichen selbst ausgibt. Dass "stty -echo" dann bash überhaupt
>beeinflusst, liegt offenkundig daran, dass bash diese Einstellung
>auswertet und das eigene Verhalten anpasst;

Und das halte ich auch für richtig so:  Schließlich soll «bash» ja
die nach Beendigung von «stty -echo» vorgefundene kanonische
zeilenweise Terminal‐Betriebsart möglichst originalgetreu
simulieren.  (Die Simulation ist ja unter anderem deshalb notwendig,
weil «bash» wegen des command line editors und wegen auto‐completion
an die Kommandozeile bereits rankommen muss, ehe sie fertig
eingetippt und abgeschickt worden ist.)  Und dazu gehört auch, den
Echo‐Zustand des Terminals nach dem Ende von «stty» zu respektieren.


Jetzt habe ich einen so schönen Beitrag geschrieben und nochmals
Versuche gemacht, und siehe da:  Es wird noch verzwickter!  War
alles für die Katz'?

Wenn ich in einem «bash» das Kommando


stty -a &

laufen lasse und diesen Versuch mehrmals wiederhole, erhalte ich
manchmal u. a. «-echo» und manchmal «echo»!  Da scheint also irgend
ein race condition zwischen der Terminal‐Umstellung, die «bash»
vornimmt und dem gleichzeitigen Lauf von «stty» stattzufinden.  Rufe
ich statt dessen

( sleep -- 1; stty -a ) &

auf, habe ich bei allen bisherigen Versuchen «-echo» erhalten.  Und
das passt ja auch dazu, dass «bash» für seine Emulation der
kanonischen Terminal‐Betriebsart das Echo ausschaltet, weil es sein
Tasten‐Echo selber machen will (und muss).  Also könnte man meinen,
dass in der Kommandozeile

( sleep -- 1; ein_Kommando ) &

«ein_Kommando» immer mit ausgeschaltetem Tasten‐Echo läuft
(vorausgesetzt, die Sekunde Wartezeit reicht dem «bash», das
Terminal wieder für sich passend einzustellen).  Also starte ich
jetzt mal

( sleep -- 1; stty -a ; bash ) &


Und natürlich sehe ich nach einer Sekunde wieder «-echo», und der
Job wird gestoppt.  Hole ich ihn in den Vordergrund, erhalte ich den
neu gestarteten interaktiven «bash».  Aber o Wunder!  Er simuliert
ein Tastenecho, und auch ein darin gestartes

stty -a

liefert «echo»!  Vermutung:  Der äußere «bash» stellt beim
«fg»‐Kommando zuerst das Tastenecho wieder an, und der in den
Vordergrund geholte «bash» holt sich wieder die
Terminal‐Einstellungen aufs Neue und arbeitet deswegen jetzt mit
eingeschaltetem (bzw. simulierten) Tastenecho.

Und jetzt vermute ich den Unterschied zum ursprünglichen
«ssh»‐Aufruf im Hintergrund:  Wenn «ssh» vom gestoppten Zustand in
den Vordergrund gebracht wird, bekommt der von ihm auf dem
entfernten Rechner gestartete «bash» davon nichts mit (vermutlich
wird der nicht einmal gemerkt haben, dass das lokale «ssh»‐Kommando
im Hintergrund und gestoppt gewesen ist).  Deswegen hat er auch
keinen Grund, nach den Terminal‐Einstellungen zu sehen und das
Tastenecho zu simulieren.

Ob der Zustand des lokalen Terminals von «ssh» überhaupt an das vom
«sshd» auf dem entfernten Rechner betriebene Pseudo‐Terminal
übermittelt wird, weiß ich nicht sicher, vermute es aber. 
Schließlich soll das entfernte Pseudo‐Terminal ja möglichst so wie
das lokale wirken.  In dem Zusammenhang muss man auch bedenken, dass
«ssh», ähnlich wie ein interaktiver Shell, sein Terminal sicher
nicht in der kanonischen Betriebsart (also zeilenweise) betreibt. 
Sonst könnte es ja auf ein Tildezeichen erst reagieren, wenn eine
ganze Zeile abgeschickt wird, und nicht sofort.

Andreas, da hast du ja ein interessantes Thema ans Licht gebracht!

[Christian Weisgerber]

On 2022-08-18, Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> Ob der Zustand des lokalen Terminals von «ssh» überhaupt an das vom
> «sshd» auf dem entfernten Rechner betriebene Pseudo‐Terminal
> übermittelt wird, weiß ich nicht sicher, vermute es aber. 

Ja, wird er.

[Christian Weisgerber]

On 2022-08-18, Helmut Waitzmann <nn.th...@xoxy.net> wrote:

>>Praktisch alle Shells im interaktiven Betrieb
>>(1) sichern die TTY-Einstellungen,
>>(2) setzen eigene Einstellungen, während sie am Prompt Eingaben
>> entgegennehmen,
>>(3) schalten vor der Befehlsausführung auf die gesichterten
>> Einstellungen zurück,
>>(4) nachdem der Befehl beendet ist, gehe zu (1).
>

> Ja, das ist richtig.  Aber Shells tun gut daran, bei der Abarbeitung
> von (2) und anschließender Verwendung des Terminals bei der
> Entgegennahme von Eingaben am Prompt sich an (1) zu orientieren: 
> Beispielsweise sollten sie gerade die Echo‐Einstellungen von (1)
> beachten:

tcsh sieht das explizit anders: In der Standardeinstellung wird
dort -echo nicht nur am Shellprompt ignoriert, sondern für die
nächste Befehlsausführung wieder eingeschaltet.

[Christian Weisgerber]

On 2022-08-18, Christian Weisgerber <na...@mips.inka.de> wrote:

> Praktisch alle Shells im interaktiven Betrieb
> (1) sichern die TTY-Einstellungen,
> (2) setzen eigene Einstellungen, während sie am Prompt Eingaben
> entgegennehmen,
> (3) schalten vor der Befehlsausführung auf die gesichterten
> Einstellungen zurück,
> (4) nachdem der Befehl beendet ist, gehe zu (1).

Und darin steckt schon die Erklärung: Wird ein Befehl in den
Hintergrund geschickt, dann setzt die Shell unmittelbar danach
wieder ihr eigene Einstellungen am Prompt.

Wenn dann der im Hintergrund laufende ssh-Prozess die TTY-Einstellungen
ausliest, bekommt er nicht diejenigen für die Befehlsausführung,
sondern jene vom Shellprompt - und übermittelt diese dann an die
Gegenseite, welche sie auf dem dortigen Pseudo-TTY einstellt.
(Helmut hat das in seinem etwas langatmigen Beitrag prinzipiell auch
schon geschrieben.)

Also kein Bug, sondern letztlich ein Fall von "Don't do that then".

> Mit tcsh dagegen tritt der Effekt gar nicht auf

tcsh nagelt allerlei TTY-Einstellungen fest, damit das TTY eben
nicht in einem seltsamen Modus ist. Siehe "Terminal management" und
"setty" in der Manpage.

[Christian Weisgerber]

On 2022-08-18, Christian Weisgerber <na...@mips.inka.de> wrote:

>> Ob der Zustand des lokalen Terminals von «ssh» überhaupt an das vom
>> «sshd» auf dem entfernten Rechner betriebene Pseudo‐Terminal
>> übermittelt wird, weiß ich nicht sicher, vermute es aber. 
>
> Ja, wird er.

Wer sich anschauen will, was da übermittelt wird, hier ist die
Instrumentierung für den OpenSSH-Client:

diff /usr/src
commit - d7ab08139e00b2370627149e410fa8ac15aed644
path + /usr/src
blob - 2796f178700e52313f2ebabec27c822edff8fd79
file + usr.bin/ssh/ttymodes.c
--- usr.bin/ssh/ttymodes.c
+++ usr.bin/ssh/ttymodes.c
@@ -271,7 +271,9 @@ ssh_tty_make_modes(struct ssh *ssh, int fd, struct ter

/* Store input and output baud rates. */
obaud = speed_to_baud(cfgetospeed(&tio));
+ logit("obaud = %d", obaud);
ibaud = speed_to_baud(cfgetispeed(&tio));
+ logit("ibaud = %d", ibaud);
if ((r = sshbuf_put_u8(buf, TTY_OP_OSPEED)) != 0 ||
(r = sshbuf_put_u32(buf, obaud)) != 0 ||
(r = sshbuf_put_u8(buf, TTY_OP_ISPEED)) != 0 ||
@@ -280,18 +282,24 @@ ssh_tty_make_modes(struct ssh *ssh, int fd, struct ter

/* Store values of mode flags. */
#define TTYCHAR(NAME, OP) \
+ { \
+ logit("%s = %d", #NAME, tio.c_cc[NAME]); \
if ((r = sshbuf_put_u8(buf, OP)) != 0 || \
(r = sshbuf_put_u32(buf, tio.c_cc[NAME])) != 0) \
- fatal_fr(r, "compose %s", #NAME);
+ fatal_fr(r, "compose %s", #NAME); \
+ }

#define SSH_TTYMODE_IUTF8 42 /* for SSH_BUG_UTF8TTYMODE */

#define TTYMODE(NAME, FIELD, OP) \
+ { \
+ logit("%s = %d", #NAME, ((tio.FIELD & NAME) != 0)); \
if (OP == SSH_TTYMODE_IUTF8 && (ssh->compat & SSH_BUG_UTF8TTYMODE)) { \
debug3_f("SSH_BUG_UTF8TTYMODE"); \
} else if ((r = sshbuf_put_u8(buf, OP)) != 0 || \
(r = sshbuf_put_u32(buf, ((tio.FIELD & NAME) != 0))) != 0) \
- fatal_fr(r, "compose %s", #NAME);
+ fatal_fr(r, "compose %s", #NAME); \
+ }

#include "ttymodes.h"