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 ">filename 2>&1" pour modifier le nom du fichier de redirection par défaut.
exemple nohup
[root@pythontab ~]# nohup ping m.sbmmt.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 m.sbmmt.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 processus enfant du terminal qui accepte le HUP signal, alors naturellement il ne sera plus 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 m.sbmmt.com [root@pythontab ~]# ps -ef |grep m.sbmmt.com root 31094 1 0 07:28 ? 00:00:00 ping m.sbmmt.com root 31102 29217 0 07:29 pts/4 00:00:00 grep m.sbmmt.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 une autre petite astuce 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 être visualisé à travers les travaux. Voyons pourquoi cela fonctionne pour éviter le signal HUP.
Exemple de sous-shell
[root@pythontab ~]# (ping m.sbmmt.com &) [root@pythontab ~]# ps -ef |grep m.sbmmt.com root 16270 1 0 16:13 pts/4 00:00:00 ping m.sbmmt.com root 16278 15362 0 16:13 pts/4 00:00:00 grep m.sbmmt.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!