Чому мій wget не помер після втрати з'єднання ssh?

Я прийшов sshдо свого сервера і побіг, wget -r -np zzz.aaa/bbb/cccі він почав працювати. Тоді мій зв’язок з Інтернетом (у мене вдома) перервався, і я хвилювався, вважаючи, що wgetце було hupпед, оскільки sshз'єднання було втрачене, і тому термінал загинув. Але тоді я sshдо свого сервера зрозумів, що він все ще працює, і вкладає вихід wget.logі завантажує речі. Може хтось, будь ласка, пояснить мені, що могло статися тут?

Це те, що psдає мені:

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

Що це означає (знак питання) ?у колонці tty?

Програми (та сценарії) можуть ігнорувати більшість сигналів, крім кількох подібних KILL. HUPСигнал можна зловити і ігнорувати , якщо програмне забезпечення так хоче.

Це з src/main.cз wgetджерел (версія 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.  */

Трохи далі встановлений обробник сигналу:

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

Так що , схоже wget, що не звертаючи уваги на HUPсигнал, але він вирішує продовжити обробку з виходом перенаправлений в файл журналу.

Запитано в коментарях: Сенс ?у TTYстовпці виводу з psзапитання полягає в тому, що wgetпроцес більше не асоціюється з терміналом / TTY. TTY пішов, коли з'єднання SSH знизилося.

Просто : wgetне перериває SIGHUP. Це все-таки відбувається SIGTERMі SIGINTхоча.

Там немає нічого на manсторінці , але якщо ви послали SIGHUPдо wgetпроцесу , то ви отримаєте в терміналі:

# 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'.