Pourquoi mon wget n'est-il pas mort après la perte de connexion ssh?

13

Je suis sshallé sur mon serveur et j'ai couru wget -r -np zzz.aaa/bbb/cccet il a commencé à fonctionner. Ensuite, ma connexion Internet (chez moi) a été interrompue et je me suis inquiété en supposant que cela wgetavait été hupinterrompu car la sshconnexion était perdue et donc le terminal était mort. Mais ensuite, j'ai sshédité sur mon serveur et j'ai réalisé qu'il fonctionnait toujours et mettait la sortie wget.loget téléchargeait des trucs. Quelqu'un peut-il m'expliquer ce qui aurait pu se passer ici?

C'est ce psqui me donne:

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

Que signifie (point d'interrogation) ?dans la colonne de tty?

— yukashima huksay
source

Notez que sur un système moderne en cours d'exécution logind, le comportement par défaut de logindest de supprimer (SIGTERM) tous les processus appartenant à un utilisateur lorsque l'utilisateur se déconnecte. Ce comportement est donc spécifique au système.

— Daniel Pryden

@Dan Mon système est ubuntu 16.04

— yukashima huksay

2

Je crois qu'Ubuntu 16.04 est un système systemd / logind, mais le logind.conf par défaut d'Ubuntu est défini explicitement KillUserProcesses=no.

— Daniel Pryden

21

Les programmes (et scripts) peuvent choisir d'ignorer la plupart des signaux, à l'exception de quelques-uns KILL. Le HUPsignal peut être capturé et ignoré si le logiciel le souhaite.

Ceci provient src/main.cdes wgetsources (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.  */

Un peu plus loin, le gestionnaire de signaux est installé:

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

Il semble wgetdonc ne pas ignorer le HUPsignal, mais il choisit de continuer le traitement avec sa sortie redirigée vers le fichier journal.

Demandé dans les commentaires: La signification de ?dans la TTYcolonne de la sortie de psla question est que le wgetprocessus n'est plus associé à un terminal / ATS. Le TTY a disparu lorsque la connexion SSH a été interrompue.

— Kusalananda
source

1

Je pense qu'il serait utile que vous ajoutiez également le sens de? en tty.

— yukashima huksay

Oui, j'ai appris ça à la dure. Tous les processus ne meurent pas lorsque ssh tombe. Il est bon de savoir exactement pourquoi.

— Doug

2

Alternativement, prenez l'habitude d'utiliser l' écran et jamais les HUP.

— Harper - Réintègre Monica le

8

Simple : wgetne s'arrête pas SIGHUP. Il le fait SIGTERMet SIGINTpourtant.

Il n'y a rien sur la manpage mais si vous avez envoyé SIGHUPun wgetprocessus, vous obtenez ceci dans le terminal:

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

1

Merci. Je pense que c'est mieux si vous ajoutez également la kill -HUP pidcommande pour montrer comment on peut envoyer SIGHUPà un processus.

— yukashima huksay