Voici une définition courante dun processus darrière-plan:
« Un processus darrière-plan est un programme qui sexécute sans intervention de lutilisateur. nombre de processus darrière-plan peuvent être exécutés sur un système dexploitation multitâche, tel que Linux, pendant que lutilisateur interagit avec le processus de premier plan. Certains processus darrière-plan, tels que les démons, par exemple, ne nécessitent aucune intervention de lutilisateur. Dautres sont simplement temporairement en arrière-plan pendant lutilisateur est occupé avec le programme actuellement en cours dexécution au premier plan. Ainsi, cet autre processus peut être en veille et occuper de lespace déchange, jusquà ce quil soit activé, ce qui en fait actuellement un processus en arrière-plan. «
Compte tenu de cette définition, Cela ne ferait-il pas un processus comme apache2 un processus darrière-plan puisquil ninteragit jamais avec lentrée utilisateur dans le terminal? Et ne prendrait-il pas en compte la plupart des processus darrière-plan, puisque la plupart des processus exécutés sur un système ne traitent pas les entrées utilisateur dans le terminal? Curieusement, je ne considérerais pas personnellement apache2 comme un processus darrière-plan car un utilisateur interagit avec lui via des requêtes http (mais pas un terminal).
Commentaires
- Je pense quil y a deux définitions ici. Lune concerne lentrée utilisateur (si un processus peut accepter lentrée utilisateur, comme le terminal). Lautre est de savoir si un processus est en veille et assis sur lespace déchange ou non. Ici, vous pouvez se référer à ces deux processus en tant que processus darrière-plan, ce qui rend le terme déroutant
Réponse
Un processus de premier plan ne nécessite une interaction de lutilisateur. Vous pouvez faire
cp very_large_file destination et cela bloquerait votre terminal jusquà ce que la copie soit terminée et serait considéré comme un processus de premier plan sans interaction de lutilisateur. Le point il sagit ici de savoir si le processus bloque lexécution dautres processus jusquà ce quil se termine.
Vous pouvez faire un processus de premier plan en arrière-plan:
1- Ajout dune esperluette ( & ) à la fin de votre ligne de commande:
cp very_large_file destination & 2- Arrêt dun processus de premier plan puis mise en arrière-plan:
cp very_large_file destination CTRL + Z
bg Maintenant apache2 compterait certainement comme un processus darrière-plan: oui vous pouvez interagir avec lui via des requêtes http mais il écoute simplement sur le port 80 (par défaut) en attendant une telle requête: il ne bloque pas le système tant que lutilisateur na pas fait une requête.
Et pourquoi vous opposez-vous à ce que la plupart des processus soient considérés comme des processus darrière-plan? Cest en effet normal dans un « système dexploitation multi-tâches ».
Commentaires
- Par curiosité, si jai un programme qui bloque mais il sexécute dans une session écran GNU ou tmux, puis je quitte cette session écran / tmux et retourne le contrôle au terminal (mais bien sûr, ils ignorent le signal HUP (raccrochage) afin quils fonctionnent toujours), seraient-ils considérés comme un arrière-plan traiter? Je suppose que vous diriez quil sagit de processus de premier plan car dans leur session, ils bloquent, même sils ne bloquent pas dans le terminal principal.
- @JohnMerlino Je dirais que
screen/tmuxest le processus de premier plan dans ce cas et lorsque vous " renvoyez le contrôle à un terminal " vous lenvoyez en arrière-plan.
Réponse
Il existe deux définitions courantes de «Processus darrière-plan», un en termes généraux, et un précis et spécifique à unix.
Dans un sens large, vous pouvez appeler «processus darrière-plan» tout processus qui ninteragit pas avec lutilisateur assis au console. En ce sens, Apache est un processus darrière-plan.
Dans la terminologie Unix, le «processus darrière-plan» a une définition précise. Un processus darrière-plan est un processus qui est lancé à partir dun terminal mais qui est actuellement interdit dinteragir avec le ter minal. (Je simplifie en ne considérant pas les groupes de processus.) Vous obtenez généralement un processus en arrière-plan en démarrant un travail en arrière-plan dans un shell:
$ myprogram & [1] 12345 $ ou en démarrant un programme, puis le suspendre et le laisser continuer en arrière-plan:
$ myprogram ^Z [1]+ Stopped myprogram $ bg [1]+ myprogram & $ Si vous démarrez un programme sans & , il est au premier plan. Il ne peut y avoir quun seul processus au premier plan dans un terminal donné à la fois. (Ou plus généralement, un seul groupe de processus, si le processus de premier plan démarre certains sous-processus.) Les modules internes du shell bg et fg changent le processus est au premier plan. Lorsquun processus est en arrière-plan, sil tente de lire ou décrire sur le terminal, il est arrêté par un signal SIGTTIN ou SIGTTOUT .
Je trouve votre intuition quApache nest pas un processus darrière-plan car il interagit avec lutilisateur via HTTP étrange. Apache ninteragit pas avec lutilisateur: il interagit avec un navigateur Web distant (qui interagit avec lutilisateur) ou un client automatisé (qui ninteragit pas avec lutilisateur). Si vous considérez un processus qui « interagit avec un processus interactif comme un processus interactif, alors tout processus est interactif, ce qui en fait un concept inutile.
La définition que vous citez associe les processus darrière-plan aux processus inactifs. Il ny a aucune raison pour laquelle un processus darrière-plan serait en veille ou échangé plus quun processus de premier plan. Un processus en arrière-plan peut effectuer des calculs lourds, par exemple. À linverse, si lutilisateur séloigne de la console et quil existe dautres processus actifs, les processus de premier plan peuvent être remplacés.