Pourquoi certains programmes exécutés à partir de Terminal à l'aide de '&' se ferment-ils alors que Terminal ne fonctionne pas et d'autres non?

Je me demandais juste, par exemple quand je lance qtoxavec:

qtox &

Et puis fermez Terminal, qtoxferme avec lui. Cependant lors de l'exécution etherapeavec:

sudo etherape &

La fermeture du terminal ne ferme pas et ne cause aucun problème à Etherape. Et parmi les différentes applications, il existe des comportements différents, certains se ferment lorsque Terminal est fermé, d'autres non, comment se fait-il? Pourquoi certains ferment-ils alors que d'autres ne le font pas? J'utilise Ubuntu GNOME 15.10 avec GNOME 3.18.

command-line sudo execute-command

— kos
source

Serait-ce que vous ouvrez un terminal, vous exécutez qtox, vous fermez le terminal, tout vous !! Mais la seconde vous ouvre le terminal, sudo exécute etherape, maintenant vous fermez votre terminal, mais sudo continue de fonctionner jusqu'à ce que sudo se ferme?

— Ken Mollerup

Eh bien, si vous ne voulez pas qtoxquitter lorsque vous fermez le terminal, vous pouvez toujours l'exécuter avec nohup qtox &.

— Terrance

@Terrance: Eh bien, dans cette question, je demandais spécifiquement pourquoi, pas comment ... Ce serait mon autre question ... :)

@ParanoidPanda Ah, bon point. Ma faute. =)

— Terrance

Lorsque vous fermez un terminal, le terminal envoie un signal SIGHUP au shell; le shell, à son tour, envoie un signal SIGHUP à tous ses groupes de processus enfants, qui incluent des groupes de processus en arrière-plan;

La façon dont chaque processus réagira au signal dépend entièrement du processus: si le processus n'a pas défini de gestionnaire pour le signal et dit au noyau (via un appel système tel que signal()ou sigaction()) qu'il souhaite le gérer, le noyau s'exécute le gestionnaire par défaut du signal, qui en cas de signal SIGHUP consiste à terminer le processus.

Cependant, lorsque vous exécutez une commande avec sudo, l'UID du sudoprocessus et de son processus enfant est défini sur 0(root); en général, à moins que l'UID du processus envoyant le signal soit 0(root) ou identique au processus cible, le noyau rejette le signal (c'est-à-dire qu'un processus ne peut pas envoyer de signaux à un processus appartenant à un autre utilisateur, à moins que le processus l'envoi du signal appartient à root); c'est pourquoi un processus exécuté par l'utilisateur tel que l'instance Bash exécutée par le terminal ne peut pas SIGHUP un sudoprocessus et, en fin de compte, la fermeture d'un terminal n'affecte pas un processus démarré avec sudo.

— kos
source

Et c'est pourquoi nous avons besoin nohupdevant ces commandes qui se ferment avec SIGHUP :) Upgoated

— Sergiy Kolodyazhnyy

Je pense qu'il n'y a rien de magique sudo. sudoexécute simplement la commande en tant qu’autre utilisateur et vous ne pouvez pas envoyer de signal aux processus des autres utilisateurs. Tu vois man 2 kill.

— el.pescado

@ el.pescado Alors, est-ce sudoune sorte de pauvre nohup?

— Hagen von Eitzen

@HagenvonEitzen Si vous voulez, mais je m'abstiendrais fortement d'exécuter une commande qui ne nécessite pas sudode sudopour son nohupeffet secondaire, compte tenu de tous les autres inconvénients.

— kos

@Serg dont nous n'avons pas besoin nohup, il crée des nohup.outfichiers inutiles après. Utilisez disownplutôt la commande intégrée.

— Ruslan