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

Lösung 1:

Änderung für 2016:

Diese Fragen und Antworten sind älter als das systemd v230-Debakel. Ab systemd v230 ist die neue Standardeinstellung, alle untergeordneten Elemente einer beendenden Anmeldesitzung zu töten, unabhängig davon, welche historisch gültigen Vorkehrungen getroffen wurden, um dies zu verhindern. Das Verhalten kann durch Setzen von KillUserProcesses=no geändert werden in /etc/systemd/logind.conf , oder umgangen werden, indem die systemd-spezifischen Mechanismen zum Starten eines Daemons im Userspace verwendet werden. Diese Mechanismen sind nicht Gegenstand dieser Frage.

Der folgende Text beschreibt, wie die Dinge im UNIX-Designspace traditionell länger funktioniert haben, als es Linux gibt.

Sie werden getötet, aber nicht unbedingt sofort. Es hängt davon ab, wie lange es dauert, bis der SSH-Daemon entscheidet, dass Ihre Verbindung tot ist. Was folgt, ist eine längere Erklärung, die Ihnen helfen wird zu verstehen, wie es tatsächlich funktioniert.

Wenn Sie sich angemeldet haben, hat der SSH-Daemon Ihnen ein Pseudo-Terminal zugewiesen und es an die konfigurierte Anmelde-Shell 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, wird letztendlich seine Vorfahren auf diese Shell zurückführen. Dies können Sie mit der pstree beobachten Befehl.

Wenn der Ihrer Verbindung zugeordnete SSH-Daemon-Prozess entscheidet, dass Ihre Verbindung tot ist, sendet er ein Auflegesignal (SIGHUP ) an die Login-Shell. Dies teilt der Shell mit, dass Sie verschwunden sind und dass sie nach sich selbst mit dem Aufräumen beginnen sollte. Was an diesem Punkt passiert, ist Shell-spezifisch (suchen Sie die Dokumentationsseite nach „HUP“), aber zum größten Teil wird es anfangen, SIGHUP zu senden damit verbundene Jobs auszuführen, bevor es beendet wird. Jeder dieser Prozesse wird seinerseits beim Empfang dieses Signals das tun, wofür er konfiguriert ist. In der Regel bedeutet das Abbruch. Wenn diese Jobs eigene Jobs haben, wird das Signal oft auch weitergegeben.

Die Prozesse, die ein Auflegen des steuernden Terminals überleben, sind diejenigen, die sich entweder selbst von einem Terminal getrennt haben (Daemon-Prozesse, die Sie darin gestartet haben), oder solche, die mit einem vorangestellten nohup aufgerufen wurden Befehl. (d. h. „nicht auflegen“) Daemons interpretieren das HUP-Signal unterschiedlich; Da sie kein steuerndes Terminal haben und nicht automatisch ein HUP-Signal empfangen, wird es stattdessen als manuelle Anforderung des Administrators zum Neuladen der Konfiguration umfunktioniert. Ironischerweise bedeutet dies, dass die meisten Admins die „Hangup“-Nutzung dieses Signals für Nicht-Daemons erst viel, viel später lernen. Deshalb liest du das hier!

Terminal-Multiplexer sind eine gängige Methode, um Ihre Shell-Umgebung zwischen Verbindungsabbrüchen intakt zu halten. Sie ermöglichen es Ihnen, sich von Ihren Shell-Prozessen so zu lösen, dass Sie sie später wieder anhängen können, unabhängig davon, ob diese Trennung versehentlich oder absichtlich war. tmux und screen sind die beliebtesten; Die Syntax für ihre Verwendung geht über den Rahmen Ihrer Frage hinaus, aber es lohnt sich, sie zu untersuchen.

Ich wurde gebeten, näher darauf einzugehen, wie lange es dauert, bis der SSH-Daemon entscheidet, dass Ihre Verbindung tot ist. Dies ist ein Verhalten, das für jede Implementierung eines SSH-Daemons spezifisch ist, aber Sie können sich darauf verlassen, dass alle beendet werden, wenn eine Seite die TCP-Verbindung zurücksetzt. Dies geschieht schnell, wenn der Server versucht, in den Socket zu schreiben und die TCP-Pakete nicht bestätigt werden, 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, serverseitig in den PTY zu schreiben. (Server->Client)
• Der Benutzer, der versucht, auf der Clientseite in den PTY zu schreiben. (Client->Server)
• Keepalives jeglicher Art. Diese werden normalerweise nicht standardmäßig aktiviert, weder vom Client noch vom Server, und es gibt normalerweise zwei Varianten:Anwendungsebene und TCP-basiert (d. h. SO_KEEPALIVE ). Keepalives laufen darauf hinaus, dass entweder der Server oder der Client selten Pakete an die andere Seite sendet, selbst wenn sonst nichts einen Grund hätte, in den Socket zu schreiben. Obwohl dies normalerweise dazu gedacht ist, Firewalls zu umgehen, die Verbindungen zu schnell abschalten, hat es den zusätzlichen Nebeneffekt, dass der Absender merkt, wenn die andere Seite nicht so viel schneller antwortet.

Hier gelten die üblichen Regeln für TCP-Sessions:Kommt es zu einer Unterbrechung der Verbindung zwischen Client und Server, aber keine Seite versucht während des Problems, ein Paket zu senden, bleibt die Verbindung bestehen, sofern beide Seiten danach antworten und das erwartete TCP empfangen Sequenznummern.

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

Lösung 2:

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

Wie @Michael Hampton und andere erwähnt haben, können Sie Tools wie tmux verwenden oder screen Terminals zu trennen/wieder zu verbinden, ohne deren Inhalt zu verlieren (d. h. untergeordnete Prozesse).

Zusätzlich können Sie mit einem kaufmännischen Und & einen Prozess in den Hintergrund versetzen und verwenden Sie dann den Befehl disown um sie von der aktuellen Shell zu trennen.

# 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
%

Lösung 3:

Nein, alle Programme, die noch mit dem Terminal verbunden sind und nicht mit so etwas wie nohup in den Hintergrund gestellt wurden , würde getötet werden.

Aus diesem Grund gibt es Lösungen für virtuelle Terminals wie tmux und das ältere screen die Sitzungen erstellen, die auch dann weiterlaufen, wenn Sie getrennt sind, und mit denen Sie sich später wieder verbinden können.