Nous rencontrons souvent ce problème. Nous souhaitons exécuter des tâches à long terme sur le serveur Linux, mais la tâche échoue à mi-chemin en raison de l'instabilité du réseau. Comment éviter que la commande ne soit interférée en fermant la fenêtre du terminal localement/en déconnectant le réseau après la soumission de la commande ?
Voici trois méthodes qui peuvent facilement répondre aux besoins ci-dessus.
Analyse du problème :
Nous savons que lorsque l'utilisateur se déconnecte (déconnexion) ou que le réseau est déconnecté, le terminal recevra le signal HUP (raccrocher) et fermera tous ses processus enfants. Par conséquent, notre solution a deux manières : soit laisser le processus ignorer le signal HUP, soit laisser le processus s'exécuter dans une nouvelle session et devenir un processus enfant qui n'appartient pas à ce terminal.
Trois solutions :
nohup est sans doute la première solution à laquelle on pense. Comme son nom l'indique, le but de nohup est de faire en sorte que la commande soumise ignore le signal de raccrochage.
Nohup est très pratique à utiliser. Ajoutez simplement nohup avant la commande à traiter et l'erreur standard sera redirigée vers le fichier nohup.out par défaut. Généralement, nous pouvons ajouter "&" à la fin pour exécuter la commande en arrière-plan en même temps, ou nous pouvons utiliser ">fichiernom 2>&1" pour modifier le nom du fichier de redirection par défaut.
exemple nohup
[root@pythontab ~]# nohup ping www.pythontab.com & [1] 3059 nohup: appending output to `nohup.out' [root@pythontab ~]# ps -ef |grep 3059 root 3059 984 0 15:06 pts/3 00:00:00 ping www.pythontab.com root 3067 984 0 15:06 pts/3 00:00:00 grep 3059 [root@pythontab ~]#
nohup peut sans aucun doute empêcher notre processus d'être interrompu à mi-chemin en ignorant le signal HUP, mais si on y pense sous un autre angle, si notre processus n'appartient pas au terminal qui accepte le processus enfant du signal HUP, alors naturellement il ne sera pas affecté par le signal HUP. setsid nous aide à le faire.
L'utilisation de setsid est également très pratique. Il vous suffit d'ajouter setsid avant la commande à traiter.
Exemple setsid
[root@pythontab ~]# setsid ping www.pythontab.com [root@pythontab ~]# ps -ef |grep www.pythontab.com root 31094 1 0 07:28 ? 00:00:00 ping www.pythontab.com root 31102 29217 0 07:29 pts/4 00:00:00 grep www.pythontab.com [root@pythontab ~]#
Il convient de noter que dans l'exemple ci-dessus, notre ID de processus (PID) est 31094, et son ID parent (PPID) est 1 (c'est-à-dire est l'ID du processus d'initialisation), et non l'ID du processus du terminal actuel.
Voici un autre petit conseil sur le sous-shell. Nous savons qu'inclure un ou plusieurs noms dans "()" permet d'exécuter ces commandes dans un sous-shell, étendant ainsi de nombreuses fonctions intéressantes, dont nous allons aborder maintenant.
Lorsque nous mettons "&" à l'intérieur de "()", nous constaterons que le travail soumis n'est pas dans la liste des travaux, c'est-à-dire qu'il ne peut pas passer les travaux. Je suis venu vérifier ça sort. Voyons pourquoi cela fonctionne pour éviter le signal HUP.
Exemple de sous-shell
[root@pythontab ~]# (ping www.pythontab.com &) [root@pythontab ~]# ps -ef |grep www.pythontab.com root 16270 1 0 16:13 pts/4 00:00:00 ping www.pythontab.com root 16278 15362 0 16:13 pts/4 00:00:00 grep www.pythontab.com [root@pythontab ~]#
Comme le montre l'exemple ci-dessus, l'ID parent (PPID) du processus nouvellement soumis est 1 (le PID du processus d'initialisation), ce qui est pas le processus de l’ID de terminal actuel. Par conséquent, il n’appartient pas au processus enfant du terminal actuel et ne sera donc pas affecté par le signal HUP du terminal actuel.
Comparativement parlant, je préfère utiliser setsid, qui est simple et pratique. Bien sûr, cela dépend des préférences de chacun ici, et il n'y a pas beaucoup de différence d'effet.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!