Sous Debian (Wheezy par exemple), apt-mirror est une commande (et un paquet aussi) qui permet de se faire très facilement des dépôts locaux miroirs des dépôts officiels Debian. Pour mettre à jour ses miroirs locaux ou tout simplement pour les créer (lorsque que c'est la première fois qu'on lance la commande), il suffit de faire :
apt-mirror
Et donc la toute première fois, c'est super long car plein de téléchargements en perspective.
1. Si je lance la commande sur une console et qu'au bout d'un moment je fais Ctrl+C pour terminer le processus, j'ai bien tout qui s'arrête proprement. En effet, je reprends bien la main sur la console et, sur une autre console, entre avant et après le Ctrl+C, j'ai bien ça :
root@wheezy:~# pstree -p | grep -E '(apt-mirror|wget)' # Et puis après le Ctrl+C
root@wheezy:~#
------------------------------------------------------------------
Mais, en revanche, si au lieu de faire un Ctrl+C sur la console où j'ai lancé apt-mirror, je vais sur une autre console et je fais :
Alors je récupère bien le prompt sur la console où j'ai lancé apt-mirror mais en revanche les téléchargements (via wget) continuent toujours.
------------------------------------------------------------------
root@wheezy:~# pstree -p | grep -E '(apt-mirror|wget)' # Après le kill, les wget sont tjs là !
|-wget(25466)
|-wget(25467)
|-wget(25468)
|-wget(25469)
|-wget(25470)
|-wget(25471)
|-wget(25472)
|-wget(25473)
|-wget(25474)
|-wget(25475)
|-wget(25476)
|-wget(25477)
|-wget(25478)
|-wget(25479)
|-wget(25480)
|-wget(25481)
|-wget(25482)
|-wget(25483)
|-wget(25484)
`-wget(25485)
------------------------------------------------------------------
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
2. Ma deuxième est identique à la première sauf que cela concerne l'équivalence (enfin la présumée équivalence) entre Ctrl+Z d'un côté et "kill -s STOP" de l'autre. Si je fais un Ctrl+Z sur la console où j'ai lancé apt-mirror, tout se met bien en pause et je n'ai plus de téléchargement :
Alors je reprends bien le prompt sur la console d'apt-mirror avec le même message ("[1]+ Stopped apt-mirror"), mais les téléchargements, eux, continuent toujours :
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution d'une commande était équivalent à envoyer le signal STOP au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à quel signal ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Francois Lafont , dans le message <51ae7852$0$14010$, a écrit :
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
Ça correspond à un SIGINT. Mais surtout, ce qui explique ton problème, il est envoyé au groupe de processus. Pour ce dernier point, compare ceci :
sh -c 'xmessage coucou; echo fini' & kill -TERM $!
... et la même chose avec « -$! » à la place de « $! » pour désigner le groupe.
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution d'une commande était équivalent à envoyer le signal STOP au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à quel signal ?
C'est le signal TSTP, qui contrairement à STOP peut être bloqué par un processus. Ça permet aux applications qui modifient l'état du terminal (toutes les applications semi-graphiques) de restaurer le terminal avant d'être bloquées, par exemple.
Et c'est aussi au groupe, pas juste à un processus.
Note : tes lignes sont trop longues.
Francois Lafont , dans le message
<51ae7852$0$14010$426a74cc@news.free.fr>, a écrit :
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était
équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ?
Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
Ça correspond à un SIGINT. Mais surtout, ce qui explique ton problème, il
est envoyé au groupe de processus. Pour ce dernier point, compare ceci :
sh -c 'xmessage coucou; echo fini' &
kill -TERM $!
... et la même chose avec « -$! » à la place de « $! » pour désigner le
groupe.
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution
d'une commande était équivalent à envoyer le signal STOP au processus,
c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à
quel signal ?
C'est le signal TSTP, qui contrairement à STOP peut être bloqué par un
processus. Ça permet aux applications qui modifient l'état du terminal
(toutes les applications semi-graphiques) de restaurer le terminal avant
d'être bloquées, par exemple.
Et c'est aussi au groupe, pas juste à un processus.
Francois Lafont , dans le message <51ae7852$0$14010$, a écrit :
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
Ça correspond à un SIGINT. Mais surtout, ce qui explique ton problème, il est envoyé au groupe de processus. Pour ce dernier point, compare ceci :
sh -c 'xmessage coucou; echo fini' & kill -TERM $!
... et la même chose avec « -$! » à la place de « $! » pour désigner le groupe.
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution d'une commande était équivalent à envoyer le signal STOP au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à quel signal ?
C'est le signal TSTP, qui contrairement à STOP peut être bloqué par un processus. Ça permet aux applications qui modifient l'état du terminal (toutes les applications semi-graphiques) de restaurer le terminal avant d'être bloquées, par exemple.
Et c'est aussi au groupe, pas juste à un processus.
Note : tes lignes sont trop longues.
Francois Lafont
Bonsoir,
Le 05/06/2013 09:34, Nicolas George a écrit :
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
Ça correspond à un SIGINT.
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact que ça a sur le processus qui reçoit le signal ?
Mais surtout, ce qui explique ton problème, il est envoyé au groupe de processus. Pour ce dernier point, compare ceci :
sh -c 'xmessage coucou; echo fini' & kill -TERM $!
... et la même chose avec « -$! » à la place de « $! » pour désigner le groupe.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un processus avec tous ses enfants, c'est ça ? Par exemple :
kill -TERM -2456
va envoyer le signal au processus 2456 mais aussi à tous ses enfants, ce qui ne serait pas le cas sans le signe moins, c'est ça ?
Si c'est bien ça, alors c'est vraiment un truc que je découvre. Je pensais que lorsqu'on envoyait un signal à un processus, il en était automatiquement de même pour tous ses enfants.
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution d'une commande était équivalent à envoyer le signal STOP au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à quel signal ?
C'est le signal TSTP, qui contrairement à STOP peut être bloqué par un processus. Ça permet aux applications qui modifient l'état du terminal (toutes les applications semi-graphiques) de restaurer le terminal avant d'être bloquées, par exemple.
Et c'est aussi au groupe, pas juste à un processus.
Ok. Parfait. Merci de ton aide.
Note : tes lignes sont trop longues.
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé. En fait, à force de voir des sauts de ligne intempestifs sur les smartphones notamment j'avais décidé au niveau de mon clients mails de ne plus mettre de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me disant que ce sera à la charge des clients qui recevront mes messages de gérer les lignes trop longues comme bon leur semble mais force est de constater que j'ai eu tort.
-- François Lafont
Bonsoir,
Le 05/06/2013 09:34, Nicolas George a écrit :
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était
équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ?
Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
Ça correspond à un SIGINT.
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact
que ça a sur le processus qui reçoit le signal ?
Mais surtout, ce qui explique ton problème, il
est envoyé au groupe de processus. Pour ce dernier point, compare ceci :
sh -c 'xmessage coucou; echo fini' &
kill -TERM $!
... et la même chose avec « -$! » à la place de « $! » pour désigner le
groupe.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un
processus avec tous ses enfants, c'est ça ? Par exemple :
kill -TERM -2456
va envoyer le signal au processus 2456 mais aussi à tous ses enfants, ce
qui ne serait pas le cas sans le signe moins, c'est ça ?
Si c'est bien ça, alors c'est vraiment un truc que je découvre. Je pensais
que lorsqu'on envoyait un signal à un processus, il en était automatiquement
de même pour tous ses enfants.
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution
d'une commande était équivalent à envoyer le signal STOP au processus,
c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à
quel signal ?
C'est le signal TSTP, qui contrairement à STOP peut être bloqué par un
processus. Ça permet aux applications qui modifient l'état du terminal
(toutes les applications semi-graphiques) de restaurer le terminal avant
d'être bloquées, par exemple.
Et c'est aussi au groupe, pas juste à un processus.
Ok. Parfait. Merci de ton aide.
Note : tes lignes sont trop longues.
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé.
En fait, à force de voir des sauts de ligne intempestifs sur les smartphones
notamment j'avais décidé au niveau de mon clients mails de ne plus mettre
de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me
disant que ce sera à la charge des clients qui recevront mes messages de
gérer les lignes trop longues comme bon leur semble mais force est de
constater que j'ai eu tort.
Je pensais que faire un Ctrl+C lors de l'exécution d'une commande était équivalent à envoyer le signal TERM au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+C correspond à quel signal ?
Ça correspond à un SIGINT.
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact que ça a sur le processus qui reçoit le signal ?
Mais surtout, ce qui explique ton problème, il est envoyé au groupe de processus. Pour ce dernier point, compare ceci :
sh -c 'xmessage coucou; echo fini' & kill -TERM $!
... et la même chose avec « -$! » à la place de « $! » pour désigner le groupe.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un processus avec tous ses enfants, c'est ça ? Par exemple :
kill -TERM -2456
va envoyer le signal au processus 2456 mais aussi à tous ses enfants, ce qui ne serait pas le cas sans le signe moins, c'est ça ?
Si c'est bien ça, alors c'est vraiment un truc que je découvre. Je pensais que lorsqu'on envoyait un signal à un processus, il en était automatiquement de même pour tous ses enfants.
Donc, même question : je pensais que faire un Ctrl+Z lors de l'exécution d'une commande était équivalent à envoyer le signal STOP au processus, c'est n'est pas exact ? Mais dans ce cas, faire un Ctrl+Z correspond à quel signal ?
C'est le signal TSTP, qui contrairement à STOP peut être bloqué par un processus. Ça permet aux applications qui modifient l'état du terminal (toutes les applications semi-graphiques) de restaurer le terminal avant d'être bloquées, par exemple.
Et c'est aussi au groupe, pas juste à un processus.
Ok. Parfait. Merci de ton aide.
Note : tes lignes sont trop longues.
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé. En fait, à force de voir des sauts de ligne intempestifs sur les smartphones notamment j'avais décidé au niveau de mon clients mails de ne plus mettre de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me disant que ce sera à la charge des clients qui recevront mes messages de gérer les lignes trop longues comme bon leur semble mais force est de constater que j'ai eu tort.
-- François Lafont
Nicolas George
Francois Lafont , dans le message <51afb003$0$2568$, a écrit :
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact que ça a sur le processus qui reçoit le signal ?
Aucune. Ce sont deux signaux qui ont pour effet par défaut de terminer le programme, ils n'ont juste pas le même numéro. Certains shells vont probablement afficher différemment, mais c'est tout.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un processus avec tous ses enfants, c'est ça ?
Pas exactement. Par défaut, un processus se retrouve dans le même groupe que son père, mais il peut décider de fonder son propre groupe.
Typiquement, un shell interactif est censé créer un nouveau groupe de processus pour chaque commande qu'il lance, de sorte que quand on les passe en avant ou arrière plan, chaque commande se comporte comme un tout.
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé. En fait, à force de voir des sauts de ligne intempestifs sur les smartphones notamment j'avais décidé au niveau de mon clients mails de ne plus mettre de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me disant que ce sera à la charge des clients qui recevront mes messages de gérer les lignes trop longues comme bon leur semble mais force est de constater que j'ai eu tort.
Ce serait plus élégant si ça marchait comme ça, mais il en a été décidé autrement.
Francois Lafont , dans le message
<51afb003$0$2568$426a34cc@news.free.fr>, a écrit :
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact
que ça a sur le processus qui reçoit le signal ?
Aucune. Ce sont deux signaux qui ont pour effet par défaut de terminer le
programme, ils n'ont juste pas le même numéro. Certains shells vont
probablement afficher différemment, mais c'est tout.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un
processus avec tous ses enfants, c'est ça ?
Pas exactement. Par défaut, un processus se retrouve dans le même groupe que
son père, mais il peut décider de fonder son propre groupe.
Typiquement, un shell interactif est censé créer un nouveau groupe de
processus pour chaque commande qu'il lance, de sorte que quand on les passe
en avant ou arrière plan, chaque commande se comporte comme un tout.
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé.
En fait, à force de voir des sauts de ligne intempestifs sur les smartphones
notamment j'avais décidé au niveau de mon clients mails de ne plus mettre
de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me
disant que ce sera à la charge des clients qui recevront mes messages de
gérer les lignes trop longues comme bon leur semble mais force est de
constater que j'ai eu tort.
Ce serait plus élégant si ça marchait comme ça, mais il en a été décidé
autrement.
Francois Lafont , dans le message <51afb003$0$2568$, a écrit :
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact que ça a sur le processus qui reçoit le signal ?
Aucune. Ce sont deux signaux qui ont pour effet par défaut de terminer le programme, ils n'ont juste pas le même numéro. Certains shells vont probablement afficher différemment, mais c'est tout.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un processus avec tous ses enfants, c'est ça ?
Pas exactement. Par défaut, un processus se retrouve dans le même groupe que son père, mais il peut décider de fonder son propre groupe.
Typiquement, un shell interactif est censé créer un nouveau groupe de processus pour chaque commande qu'il lance, de sorte que quand on les passe en avant ou arrière plan, chaque commande se comporte comme un tout.
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé. En fait, à force de voir des sauts de ligne intempestifs sur les smartphones notamment j'avais décidé au niveau de mon clients mails de ne plus mettre de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me disant que ce sera à la charge des clients qui recevront mes messages de gérer les lignes trop longues comme bon leur semble mais force est de constater que j'ai eu tort.
Ce serait plus élégant si ça marchait comme ça, mais il en a été décidé autrement.
Francois Lafont
Le 06/06/2013 00:11, Nicolas George a écrit :
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact que ça a sur le processus qui reçoit le signal ?
Aucune. Ce sont deux signaux qui ont pour effet par défaut de terminer le programme, ils n'ont juste pas le même numéro. Certains shells vont probablement afficher différemment, mais c'est tout.
Ok.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un processus avec tous ses enfants, c'est ça ?
Pas exactement. Par défaut, un processus se retrouve dans le même groupe que son père, mais il peut décider de fonder son propre groupe.
Typiquement, un shell interactif est censé créer un nouveau groupe de processus pour chaque commande qu'il lance, de sorte que quand on les passe en avant ou arrière plan, chaque commande se comporte comme un tout.
C'est marrant parce que c'est vraiment la première fois que j'entends parler de cette notion de "groupe de processus". J'avais jamais fait attention jusqu'ici, avant que tu m'en parles et que je constate que la page man de kill en touche un mot :
« Negative PID values may be used to choose whole process groups; see the PGID column in ps command output. »
C'est dommage que pstree ne permette pas d'afficher ce PGID.
Qui décide du PGID ? C'est le père ou c'est le fils ?
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé. En fait, à force de voir des sauts de ligne intempestifs sur les smartphones notamment j'avais décidé au niveau de mon clients mails de ne plus mettre de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me disant que ce sera à la charge des clients qui recevront mes messages de gérer les lignes trop longues comme bon leur semble mais force est de constater que j'ai eu tort.
Ce serait plus élégant si ça marchait comme ça, mais il en a été décidé autrement.
De toute façon, pour les fins de lignes c'est la pagaille, j'ai jamais réussi à avoir une configuration satisfaisante.
-- François Lafont
Le 06/06/2013 00:11, Nicolas George a écrit :
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact
que ça a sur le processus qui reçoit le signal ?
Aucune. Ce sont deux signaux qui ont pour effet par défaut de terminer le
programme, ils n'ont juste pas le même numéro. Certains shells vont
probablement afficher différemment, mais c'est tout.
Ok.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un
processus avec tous ses enfants, c'est ça ?
Pas exactement. Par défaut, un processus se retrouve dans le même groupe que
son père, mais il peut décider de fonder son propre groupe.
Typiquement, un shell interactif est censé créer un nouveau groupe de
processus pour chaque commande qu'il lance, de sorte que quand on les passe
en avant ou arrière plan, chaque commande se comporte comme un tout.
C'est marrant parce que c'est vraiment la première fois que j'entends parler
de cette notion de "groupe de processus". J'avais jamais fait attention
jusqu'ici, avant que tu m'en parles et que je constate que la page man de kill
en touche un mot :
« Negative PID values may be used to choose whole process groups; see the
PGID column in ps command output. »
C'est dommage que pstree ne permette pas d'afficher ce PGID.
Qui décide du PGID ? C'est le père ou c'est le fils ?
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé.
En fait, à force de voir des sauts de ligne intempestifs sur les smartphones
notamment j'avais décidé au niveau de mon clients mails de ne plus mettre
de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me
disant que ce sera à la charge des clients qui recevront mes messages de
gérer les lignes trop longues comme bon leur semble mais force est de
constater que j'ai eu tort.
Ce serait plus élégant si ça marchait comme ça, mais il en a été décidé
autrement.
De toute façon, pour les fins de lignes c'est la pagaille, j'ai jamais
réussi à avoir une configuration satisfaisante.
Ok. Qu'elle est la différence entre SIGINT et SIGTERM au niveau de l'impact que ça a sur le processus qui reçoit le signal ?
Aucune. Ce sont deux signaux qui ont pour effet par défaut de terminer le programme, ils n'ont juste pas le même numéro. Certains shells vont probablement afficher différemment, mais c'est tout.
Ok.
Ok merci beaucoup. Ce que tu appelles "groupe de processus" c'est un processus avec tous ses enfants, c'est ça ?
Pas exactement. Par défaut, un processus se retrouve dans le même groupe que son père, mais il peut décider de fonder son propre groupe.
Typiquement, un shell interactif est censé créer un nouveau groupe de processus pour chaque commande qu'il lance, de sorte que quand on les passe en avant ou arrière plan, chaque commande se comporte comme un tout.
C'est marrant parce que c'est vraiment la première fois que j'entends parler de cette notion de "groupe de processus". J'avais jamais fait attention jusqu'ici, avant que tu m'en parles et que je constate que la page man de kill en touche un mot :
« Negative PID values may be used to choose whole process groups; see the PGID column in ps command output. »
C'est dommage que pstree ne permette pas d'afficher ce PGID.
Qui décide du PGID ? C'est le père ou c'est le fils ?
Ah, tu es le 2e à me faire le reproche, du coup je vais rectifier. Désolé. En fait, à force de voir des sauts de ligne intempestifs sur les smartphones notamment j'avais décidé au niveau de mon clients mails de ne plus mettre de saut de ligne ailleurs qu'au niveau des « sauts de paragraphe » en me disant que ce sera à la charge des clients qui recevront mes messages de gérer les lignes trop longues comme bon leur semble mais force est de constater que j'ai eu tort.
Ce serait plus élégant si ça marchait comme ça, mais il en a été décidé autrement.
De toute façon, pour les fins de lignes c'est la pagaille, j'ai jamais réussi à avoir une configuration satisfaisante.
-- François Lafont
Damien Wyart
* Francois Lafont in fr.comp.os.linux.configuration:
Qui décide du PGID ? C'est le père ou c'est le fils ?
Un processus hérite du pgid de son père.
Je n'ai pas trouvé grand'chose en Français qui soit un peu détaillé et fiable ; tu trouveras ici quelques compléments en Anglais : http://en.wikipedia.org/wiki/Process_group
-- DW
* Francois Lafont <francois.lafont@nospam.invalid>
in fr.comp.os.linux.configuration:
Qui décide du PGID ? C'est le père ou c'est le fils ?
Un processus hérite du pgid de son père.
Je n'ai pas trouvé grand'chose en Français qui soit un peu détaillé et
fiable ; tu trouveras ici quelques compléments en Anglais :
http://en.wikipedia.org/wiki/Process_group
* Francois Lafont in fr.comp.os.linux.configuration:
Qui décide du PGID ? C'est le père ou c'est le fils ?
Un processus hérite du pgid de son père.
Je n'ai pas trouvé grand'chose en Français qui soit un peu détaillé et fiable ; tu trouveras ici quelques compléments en Anglais : http://en.wikipedia.org/wiki/Process_group
-- DW
Damien Wyart
Je n'ai pas trouvé grand'chose en Français qui soit un peu détaillé et fiable ; tu trouveras ici quelques compléments en Anglais : http://en.wikipedia.org/wiki/Process_group
Sinon, ceci explique bien les principales notions de la gestion des processus : http://www.win.tue.nl/~aeb/linux/lk/lk-10.html
Ce support me semble également de bonne qualité : http://moss.cs.iit.edu/cs351/assets/slides-processmgmt-3.pdf
-- DW
Je n'ai pas trouvé grand'chose en Français qui soit un peu détaillé et
fiable ; tu trouveras ici quelques compléments en Anglais :
http://en.wikipedia.org/wiki/Process_group
Sinon, ceci explique bien les principales notions de la gestion des
processus :
http://www.win.tue.nl/~aeb/linux/lk/lk-10.html
Ce support me semble également de bonne qualité :
http://moss.cs.iit.edu/cs351/assets/slides-processmgmt-3.pdf
Je n'ai pas trouvé grand'chose en Français qui soit un peu détaillé et fiable ; tu trouveras ici quelques compléments en Anglais : http://en.wikipedia.org/wiki/Process_group
Sinon, ceci explique bien les principales notions de la gestion des processus : http://www.win.tue.nl/~aeb/linux/lk/lk-10.html
Ce support me semble également de bonne qualité : http://moss.cs.iit.edu/cs351/assets/slides-processmgmt-3.pdf
-- DW
Damien Wyart
* Francois Lafont in fr.comp.os.linux.configuration:
C'est dommage que pstree ne permette pas d'afficher ce PGID.
Essaie pstree -g (je ne sais pas si l'option existe sur toutes les versions).
Sinon, dans l'arbre de pstree, les fils d'un noeud de 1er niveau représentent les processus qui ont le même pgid.
-- DW
* Francois Lafont <francois.lafont@nospam.invalid>
in fr.comp.os.linux.configuration:
C'est dommage que pstree ne permette pas d'afficher ce PGID.
Essaie pstree -g
(je ne sais pas si l'option existe sur toutes les versions).
Sinon, dans l'arbre de pstree, les fils d'un noeud de 1er niveau
représentent les processus qui ont le même pgid.
