Frage SSH-Sitzung fällt ab - Wird der Befehl weiterhin ausgeführt? [Duplikat]


Diese Frage hat hier bereits eine Antwort:

Wenn ich einen Befehl ausführen würde, bevor die SSH-Verbindung unterbrochen wurde, wird der Befehl weiterhin ausgeführt?


18
2018-02-23 20:17


Ursprung




Antworten:


In den meisten Fällen, nein. Prozesse werden ein SIGHUP bei Verlust von Terminal gesendet. Sie können einen Befehl mit 'nohup' voranstellen, um das Signal zu ignorieren. Sehen:

http://en.wikipedia.org/wiki/Nohup


21
2018-02-23 20:26





Ich werde dem Thread noch einen hilfreichen Vorschlag hinzufügen, etwas, das ich vor ein paar Minuten gelernt habe:

Wenn Sie bereits einen Prozess gestartet haben, der lange dauern wird (tar-Wiederherstellung in meinem Fall) und vergessen hat, nohup davor einzufügen, können Sie immer noch verhindern, dass er beim Abmelden beendet wird.

Hier sind die Schritte:

  1. Drücken Sie Strg + Z - Dies wird den Job aussetzen
  2. Eingeben verleugnen -h% x, woher x ist die Auftragsnummer, die Sie erhalten, nachdem Sie den Auftrag ausgesetzt haben
  3. Ausführen bg um den Job in den Hintergrund zu stellen
  4. Verlasse die Schale und mach weiter mit deinem Leben :).

11
2017-09-21 22:26



+1, aber ich habe festgestellt, dass die disown Befehl ist unter Bash unter Linux nicht notwendig. Ich muss nur den Job senden, dann abmelden und der Job wird weiter ausgeführt. - njahnke


Nicht allgemein, obwohl Sie nicht wissen, welche Shell oder welches Betriebssystem Sie verwenden, ist es schwer zu sagen. Wenn Sie es zum Beispiel unter dem Bildschirm ausführen, denke ich, dass das Verhalten darin besteht, sich zu trennen und weiter zu laufen. Vielleicht haben einige andere Shells das als konfigurierbare Option.


6
2018-02-23 20:28



+1 für Erwähnung screen. manpagez.com/man/1/screen - jscott


Wie Warner oben sagt, wird das Kind des SSH-Daemon (das ist die Login-Shell und seine Kinder) bekommen SIGHUP, aber sie werden sie nicht sofort bekommen. Es wird eine Verzögerung geben, manchmal in Minuten, bevor der ssh-Daemon auf der Serverseite auf Ihrer Verbindung aufgibt. Während dieser Zeit läuft der Prozess weiter.

Wie Warner auch sagte, kann der Prozess wählen zu ignorieren SIGHUPIn diesem Fall wird es weiterlaufen, bis es eine Eingabe anfordern und dann finden muss STDIN hat geschlossen.


5
2018-02-23 20:29





Warners Antwort ist genau richtig. Alternativ können Sie den Befehl auch im Hintergrund ausführen, indem Sie ein kaufmännisches Und-Zeichen (&) an das Ende des Befehls anfügen.


0
2018-02-23 20:28





Ich habe die beste Antwort unter dem Link unten gefunden

Verliert die Verbindung zu einer SSH-Sitzung Ihre Programme?

Bearbeiten für 2016:

Diese Fragen und Antworten sind älter als das systemd v230 Debakel. Ab Systemd v230 besteht die neue Standardeinstellung darin, alle untergeordneten Elemente einer abschließenden Anmeldesitzung zu beenden, unabhängig davon, welche historisch gültigen Vorsichtsmaßnahmen getroffen wurden, um dies zu verhindern. Das Verhalten kann geändert werden, indem KillUserProcesses = no in /etc/systemd/logind.conf festgelegt wird, oder mit den systemspezifischen Mechanismen zum Starten eines Dämons im Benutzerbereich umgangen werden. Diese Mechanismen fallen nicht in den Rahmen dieser Frage.


Der folgende Text beschreibt, wie die Dinge traditionell in UNIX-Designspace länger funktionierten als Linux.

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 beendet 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 ein Pseudo-Terminal für Sie zugewiesen und an die vom Benutzer konfigurierte Login-Shell angehängt. Dies wird das steuernde Terminal genannt. Jedes Programm, das du normalerweise an diesem Punkt startest, egal wie viele Ebenen von Shells tief sind, wird letztendlich seine Herkunft in diese Shell zurückverfolgen. Sie können dies mit dem Befehl pstree beobachten.

Wenn der Ihrer Verbindung zugeordnete SSH-Daemon-Prozess entscheidet, dass Ihre Verbindung beendet ist, sendet er ein Aufhängungssignal (SIGHUP) an die Login-Shell. Dies benachrichtigt die Shell, die du verschwunden bist und dass sie anfangen sollte, nach sich selbst aufzuräumen; Was zu diesem Zeitpunkt passiert, ist Shell-spezifisch (suchen Sie auf der Dokumentationsseite nach "HUP"), aber in den meisten Fällen beginnt SIGHUP damit, die damit verbundenen Jobs zu starten, bevor es beendet wird. Jeder dieser Prozesse wiederum wird tun, was auch immer nach dem Empfang dieses Signals konfiguriert ist. Normalerweise bedeutet das Beenden. Wenn diese Jobs eigene Jobs haben, wird das Signal oft mitgereicht.

Die Prozesse, die ein Aufhängen des steuernden Terminals überleben, sind solche, die sich entweder von einem Terminal (Daemon-Prozesse, die Sie innerhalb davon gestartet haben) oder solchen, die mit einem Präfix-Nohup-Kommando aufgerufen wurden, distanzieren. (d. h. "nicht auflegen")

Terminal-Multiplexer sind eine gängige Methode, um die Shell-Umgebung zwischen den Unterbrechungen intakt zu halten. Sie ermöglichen es Ihnen, sich von Ihren Shell-Prozessen auf eine Weise zu lösen, dass Sie später wieder an sie anhängen können, unabhängig davon, ob diese Trennung zufällig oder absichtlich erfolgte. tmux und Bildschirm sind die populäreren; Die Syntax für ihre Verwendung übersteigt den Rahmen Ihrer Frage, aber es lohnt sich, sie genauer zu betrachten.

Es wurde verlangt, dass ich ausführe, "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. Sie können jedoch darauf zählen, dass alle von ihnen beendet werden, wenn eine Seite die TCP-Verbindung zurücksetzt. Dies geschieht schnell, wenn eine der Seiten versucht, in den Socket zu schreiben, und die TCP-Pakete nicht bestätigt werden, oder langsam, wenn keine Seite 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 versucht, auf Client-Seite in den PTY zu schreiben (Client-> Server).

  • Keepalives jeglicher Art. Diese sind normalerweise weder vom Client noch vom Server standardmäßig aktiviert, und normalerweise gibt es zwei Varianten: Anwendungsebene und TCP-basiert (d. H. SO_KEEPALIVE). Keepalives belaufen sich entweder darauf, dass der Server oder der Client Pakete selten an die andere Seite sendet, selbst wenn nichts sonst einen Grund hätte, in den Socket zu schreiben. Während dies normalerweise dazu gedacht ist, Firewalls zu umgehen, die Verbindungen zu schnell unterbrechen, hat dies den zusätzlichen Nebeneffekt, dass der Absender bemerkt, wenn die andere Seite nicht viel schneller antwortet.

Die üblichen Regeln für TCP-Sitzungen gelten hier: Wenn die Verbindung zwischen Client und Server unterbrochen ist, aber keine der Seiten versucht, während des Problems ein Paket zu senden, wird die Verbindung bestehen bleiben, sofern beide Seiten danach reagieren und das erwartete TCP empfangen Sequenznummern.

Wenn eine Seite entschieden hat, dass der Socket tot ist, sind die Auswirkungen in der Regel unmittelbar: 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, dass die andere tot ist, bedeutet nicht, dass der andere wurde davon benachrichtigt, und wird in der Regel offen bleiben, bis entweder versucht, auf die Verbindung zu schreiben, oder es die TCP-Reset von der anderen Seite erhält . (wenn Konnektivität zu der Zeit verfügbar war)


0
2018-05-03 13:26