Warum ist mein wget nach ssh-Verbindungsverlust nicht gestorben?

13

Ich ging sshzu meinem Server und lief wget -r -np zzz.aaa/bbb/cccund es fing an zu arbeiten. Dann meine Internetverbindung (bei mir zu Hause) bekam unterbrochen und ich habe gesorgt davon aus, dass wgetwurde hupped , weil die sshVerbindung unterbrochen wurde und deshalb hatte das Terminal gestorben. Aber dann habe ich sshauf meinem Server festgestellt, dass er noch läuft und die Ausgabe wget.logeingibt und Sachen herunterlädt. Kann mir bitte jemand erklären, was hier passiert sein könnte?

Das psgibt mir:

PID   %CPU %MEM    VSZ    RSS TTY     STAT START   TIME COMMAND
32283  0.6 29.4 179824 147088 ?       S    14:00   1:53 wget -r -np zzz.aaa/bbb/ccc

Was bedeutet es (Fragezeichen) ?in der Spalte von tty?

— Yukashima Huksay
quelle

Beachten Sie, dass auf einem modernen System logindstandardmäßig logindalle Prozesse eines Benutzers beendet werden (SIGTERM), wenn sich der Benutzer abmeldet. Dieses Verhalten ist also systemspezifisch.

— Daniel Pryden

@Dan Mein System ist Ubuntu 16.04

— Yukashima Huksay

2

Ich glaube, Ubuntu 16.04 ist ein systemd / logind-System, aber die Ubuntu-Standard-logind.conf wird explizit festgelegt KillUserProcesses=no.

— Daniel Pryden

21

Programme (und Skripte) können die meisten Signale ignorieren, mit Ausnahme einiger weniger KILL. Das HUPSignal kann abgefangen und ignoriert werden, wenn die Software dies wünscht.

Dies ist aus src/main.cden wgetQuellen (Version 1.19.2):

/* Hangup signal handler.  When wget receives SIGHUP or SIGUSR1, it
   will proceed operation as usual, trying to write into a log file.
   If that is impossible, the output will be turned off.  */

Etwas weiter unten ist der Signalhandler installiert:

  /* Setup the signal handler to redirect output when hangup is
     received.  */
  if (signal(SIGHUP, SIG_IGN) != SIG_IGN)
    signal(SIGHUP, redirect_output_signal);

Es sieht also so aus , als würde das Signal wgetnicht ignoriertHUP , aber die Verarbeitung wird fortgesetzt und die Ausgabe in die Protokolldatei umgeleitet.

In Kommentaren angefordert: Die Bedeutung von ?in der TTYSpalte der Ausgabe von psin der Frage ist, dass der wgetProzess keinem Terminal / TTY mehr zugeordnet ist. Das TTY ging weg, als die SSH-Verbindung unterbrochen wurde.

— Kusalananda
quelle

1

Ich denke, es wäre nützlich, wenn Sie auch die Bedeutung von hinzufügen? in tty.

— Yukashima Huksay

Ja, das habe ich auf die harte Tour gelernt. Nicht alle Prozesse sterben ab, wenn ssh abfällt. Es ist gut zu wissen warum.

— Doug

2

Machen Sie es sich alternativ zur Gewohnheit, Bildschirm und nie HUPs zu verwenden.

— Harper - Reinstate Monica

8

Einfach : wgetbricht nicht ab SIGHUP. Es geht aber weiter SIGTERMund weiter SIGINT.

Es ist nichts auf der manSeite, aber wenn Sie SIGHUPan einen wgetProzess gesendet haben , wird dies im Terminal angezeigt:

# in a different terminal while wget is running (with PID 12345)
kill -HUP 12345
# in the wget terminal
SIGHUP received.
Redirecting output to 'wget-log'.

— Hauke Laging
quelle

1

Vielen Dank. Ich denke, es ist besser, wenn Sie auch den kill -HUP pidBefehl hinzufügen, um zu zeigen, wie man SIGHUPan einen Prozess senden kann.

— Yukashima Huksay