it-swarm.com.de

Tötet das Trennen von einer SSH-Sitzung Ihre Programme?

Angenommen, ich werde von einer SSH-Sitzung getrennt, nachdem ich rsync oder cp oder einen anderen Befehl gestartet habe, der lange ausgeführt werden kann. Läuft dieser Befehl so lange, bis er beendet ist, nachdem ich die Verbindung getrennt habe, oder wird er nur getötet?

Ich habe mich immer gefragt.

92
fregas

Bearbeiten für 2016:

Diese Fragen und Antworten sind älter als das systemd v230-Debakel . Ab systemd v230 werden standardmäßig alle untergeordneten Elemente einer abschließenden Anmeldesitzung getötet, unabhängig davon, welche historisch gültigen Vorsichtsmaßnahmen getroffen wurden, um dies zu verhindern. Das Verhalten kann durch Setzen von KillUserProcesses=no In /etc/systemd/logind.conf Geändert oder mithilfe der systemd-spezifischen Mechanismen zum Starten eines Daemons im Userspace umgangen werden. Diese Mechanismen liegen außerhalb des Rahmens dieser Frage.

Der folgende Text beschreibt, wie Dinge in UNIX Designspace traditionell länger als Linux funktioniert haben.


Sie werden getötet, aber nicht unbedingt sofort. Dies hängt davon ab, wie lange es dauert, bis der SSH-Dämon feststellt, dass Ihre Verbindung unterbrochen ist. Was folgt, ist eine längere Erklärung, die Ihnen hilft zu verstehen, wie es tatsächlich funktioniert.

Wenn Sie sich angemeldet haben, hat der SSH-Dämon Ihnen ein Pseudo-Terminal zugewiesen und es an die konfigurierte Anmeldeshell Ihres Benutzers angehängt. Dies wird als steuerndes Terminal bezeichnet. Jedes Programm, das Sie an diesem Punkt normal starten, egal wie viele Schichten von Shells tief sind, führt letztendlich seine Abstammung auf diese Shell zurück. Sie können dies mit dem Befehl pstree beobachten.

Wenn der Ihrer Verbindung zugeordnete SSH-Dämonprozess feststellt, dass Ihre Verbindung unterbrochen ist, sendet er ein Auflegesignal (SIGHUP) an die Anmeldeshell. Dies benachrichtigt die Shell, dass Sie verschwunden sind und dass sie nach sich selbst aufräumen sollte. Was an diesem Punkt passiert, ist Shell-spezifisch (durchsuchen Sie die Dokumentationsseite nach "HUP"), aber zum größten Teil beginnt es, SIGHUP an laufende Jobs zu senden, bevor es beendet wird. Jeder dieser Prozesse führt seinerseits alles aus, wofür er beim Empfang dieses Signals konfiguriert ist. Normalerweise bedeutet das Kündigen. Wenn diese Jobs eigene Jobs haben, wird das Signal oft auch weitergegeben.

Die Prozesse, die einen Hangup des steuernden Terminals überleben, sind solche, die sich entweder von einem Terminal getrennt haben (Daemon-Prozesse, die Sie darin gestartet haben), oder solche, die mit einem vorangestellten Nohup -Befehl aufgerufen wurden. (d. h. "nicht auflegen") Daemons interpretieren das HUP-Signal anders; Da sie kein steuerndes Terminal haben und nicht automatisch ein HUP-Signal empfangen, wird es stattdessen als manuelle Anforderung des Administrators zum erneuten Laden der Konfiguration verwendet. Ironischerweise bedeutet dies, dass die meisten Administratoren die Verwendung dieses Signals für Nicht-Dämonen erst viel später lernen. Deshalb liest du das!

Terminal-Multiplexer sind eine übliche Methode, um Ihre Shell-Umgebung zwischen den Verbindungsabbrüchen intakt zu halten. Mit ihnen können Sie sich von Ihren Shell-Prozessen auf eine Weise trennen, die Sie später wieder herstellen können, unabhängig davon, ob diese Trennung versehentlich oder absichtlich erfolgte. tmux und screen sind die beliebtesten; Die Syntax für ihre Verwendung würde den Rahmen Ihrer Frage sprengen, aber es lohnt sich, sie zu untersuchen.


Ich wurde gebeten, näher zu erläutern, wie lange es dauert, bis der SSH-Dämon feststellt, dass Ihre Verbindung unterbrochen ist. Dies ist ein Verhalten, das für jede Implementierung eines SSH-Dämons spezifisch ist. Sie können sich jedoch darauf verlassen, dass alle beendet werden, wenn beide Seiten die Verbindung TCP) zurücksetzen. Dies geschieht schnell, wenn der Server dies versucht Schreiben in den Socket und die TCP Pakete werden nicht bestätigt oder langsam, wenn nichts versucht, in den PTY zu schreiben.

In diesem speziellen Kontext sind die Faktoren, die am wahrscheinlichsten einen Schreibvorgang auslösen, folgende:

  • Ein Prozess (normalerweise der im Vordergrund), der versucht, auf der Serverseite in den PTY zu schreiben. (Server-> Client)
  • Der Benutzer, der versucht, auf der Clientseite in das PTY zu schreiben. (Client-> Server)
  • Keepalives jeglicher Art. Diese werden normalerweise weder vom Client noch vom Server standardmäßig aktiviert, und es gibt normalerweise zwei Varianten: Anwendungsebene und TCP basiert (dh SO_KEEPALIVE). Keepalives belaufen sich auf Entweder der Server oder der Client senden selten Pakete an die andere Seite, auch wenn sonst nichts einen Grund hätte, in den Socket zu schreiben. Dies ist normalerweise dazu gedacht, Firewalls zu umgehen, die Verbindungen zu schnell auslaufen lassen, hat jedoch den zusätzlichen Nebeneffekt Der Absender merkt, wenn die andere Seite nicht so schnell reagiert.

Hier gelten die üblichen Regeln für TCP -Sitzungen: Wenn die Konnektivität zwischen Client und Server unterbrochen wird, aber keine Seite versucht, während des Problems ein Paket zu senden, bleibt die Verbindung bestehen, sofern beide Die Seiten reagieren danach und erhalten die erwarteten TCP Sequenznummern).

Wenn eine Seite entschieden hat, dass der Socket tot ist, sind die Auswirkungen normalerweise sofort: Der sshd-Prozess sendet HUP und beendet sich selbst (wie zuvor beschrieben), oder der Client benachrichtigt den Benutzer über das erkannte Problem. Es ist erwähnenswert, dass nur weil eine Seite denkt, die andere sei tot, dies nicht bedeutet, dass die andere Seite darüber informiert wurde. Die verwaiste Seite der Verbindung bleibt normalerweise geöffnet, bis sie entweder versucht, darauf zu schreiben, und eine Zeitüberschreitung auftritt oder von der anderen Seite ein TCP Reset) erhält (wenn zu diesem Zeitpunkt Konnektivität verfügbar war). Die in dieser Antwort beschriebene Bereinigung erfolgt erst, wenn der Server dies bemerkt hat.

120
Andrew B

Wie andere bereits erwähnt haben, ist alles, was darin läuft, verschwunden, sobald Sie die Verbindung zu ssh trennen.

Wie @ Michael Hampton und andere erwähnt haben, können Sie Tools wie tmux oder screen verwenden, um die Verbindung zu Terminals zu trennen/wieder herzustellen, ohne deren Inhalt zu verlieren (d. H. Untergeordnete Prozesse).

Zusätzlich können Sie einen Prozess mit einem kaufmännischen Und & In den Hintergrund stellen und dann mit dem Befehl disown die Zuordnung zu der aktuellen Shell aufheben.

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from Shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%
23
slm

Nein, alle Programme, die noch an das Terminal angeschlossen sind und nicht mit Nohup in den Hintergrund gestellt wurden, werden beendet.

Aus diesem Grund gibt es virtuelle Terminallösungen wie tmux und die älteren screen, die Sitzungen erstellen, die auch dann ausgeführt werden, wenn Sie nicht verbunden sind und an die Sie später erneut anschließen können.

14
Michael Hampton