kill sur un processus "apt-mirror"

Le
Francois Lafont
Bonsoir,

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)' # Pendant l'exécution de apt-mirror
|-login(2335)bash(2341)apt-mirror(25296)-+-wget(25331)
| |-wget(25332)
| |-wget(25333)
| |-wget(25334)
| |-wget(25335)
| |-wget(25336)
| |-wget(25337)
| |-wget(25338)
| |-wget(25339)
| |-wget(25340)
| |-wget(25341)
| |-wget(25342)
| |-wget(25343)
| |-wget(25344)
| |-wget(25345)
| |-wget(25346)
| |-wget(25347)
| |-wget(25348)
| |-wget(25349)
| `-wget(25350)


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 :


root@wheezy:~# pstree -p | grep -E '(apt-mirror|wget)'
|-login(2335)bash(2341)apt-mirror(25416)-+-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)
root@wheezy:~# kill -s TERM 25416


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 :


root@wheezy:~# ps aux | grep -E '(apt-mirror|wget)'
root 25508 4.8 16.8 108704 85568 tty1 T 01:10 0:19 /usr/bin/perl -w /usr/bin/apt-mirror
root 25545 0.6 0.7 36876 3908 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.0 -i /depots/var/archive-urls.0
root 25546 0.5 0.7 36876 3900 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.1 -i /depots/var/archive-urls.1
root 25547 0.5 0.7 36876 3972 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.2 -i /depots/var/archive-urls.2
root 25548 0.6 0.7 36876 4028 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.3 -i /depots/var/archive-urls.3
root 25549 0.5 0.7 36996 4068 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.4 -i /depots/var/archive-urls.4
root 25550 0.4 0.8 37128 4204 tty1 T 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.5 -i /depots/var/archive-urls.5
root 25551 0.5 0.8 37004 4164 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.6 -i /depots/var/archive-urls.6
root 25552 0.6 0.7 36876 4000 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.7 -i /depots/var/archive-urls.7
root 25553 0.5 0.8 37260 4396 tty1 T 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.8 -i /depots/var/archive-urls.8
root 25554 0.5 0.8 37260 4372 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.9 -i /depots/var/archive-urls.9
root 25555 0.4 0.8 37140 4300 tty1 T 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.10 -i /depots/var/archive-urls.10
root 25556 0.4 0.8 37124 4276 tty1 T 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.11 -i /depots/var/archive-urls.11
root 25557 0.6 0.7 36876 3988 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.12 -i /depots/var/archive-urls.12
root 25558 0.5 0.7 36876 4024 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.13 -i /depots/var/archive-urls.13
root 25559 0.5 0.7 36876 4032 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.14 -i /depots/var/archive-urls.14
root 25560 0.5 0.8 36996 4092 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.15 -i /depots/var/archive-urls.15
root 25561 0.5 0.7 36876 4036 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.16 -i /depots/var/archive-urls.16
root 25562 0.5 0.7 36876 4020 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.17 -i /depots/var/archive-urls.17
root 25563 0.5 0.7 36876 4024 tty1 T 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.18 -i /depots/var/archive-urls.18
root 25564 0.5 0.7 36876 4068 tty1 T 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.19 -i /depots/var/archive-urls.19


En revanche, si à la place du Ctrl+Z, je fais sur une autre console un :


kill -s STOP 25508 # pid du processus apt-mirror


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 :


root@wheezy:~# ps aux | grep -E '(apt-mirror|wget)'
root 25508 3.1 16.8 108704 85568 tty1 T 01:10 0:19 /usr/bin/perl -w /usr/bin/apt-mirror
root 25545 0.4 0.7 36876 3988 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.0 -i /depots/var/archive-urls.0
root 25546 0.4 0.7 36876 3964 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.1 -i /depots/var/archive-urls.1
root 25547 0.3 0.7 36876 3972 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.2 -i /depots/var/archive-urls.2
root 25548 0.4 0.7 36876 4028 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.3 -i /depots/var/archive-urls.3
root 25549 0.4 0.7 36996 4068 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.4 -i /depots/var/archive-urls.4
root 25550 0.3 0.8 37128 4204 tty1 S 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.5 -i /depots/var/archive-urls.5
root 25551 0.3 0.8 37004 4184 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.6 -i /depots/var/archive-urls.6
root 25552 0.4 0.7 36876 4004 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.7 -i /depots/var/archive-urls.7
root 25553 0.3 0.8 37260 4396 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.8 -i /depots/var/archive-urls.8
root 25554 0.3 0.8 37260 4372 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.9 -i /depots/var/archive-urls.9
root 25555 0.3 0.8 37140 4324 tty1 S 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.10 -i /depots/var/archive-urls.10
root 25556 0.3 0.8 37128 4280 tty1 S 01:11 0:01 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.11 -i /depots/var/archive-urls.11
root 25557 0.4 0.7 36876 3988 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.12 -i /depots/var/archive-urls.12
root 25558 0.3 0.7 36876 4024 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.13 -i /depots/var/archive-urls.13
root 25559 0.4 0.7 36876 4032 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.14 -i /depots/var/archive-urls.14
root 25560 0.3 0.8 36992 4104 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.15 -i /depots/var/archive-urls.15
root 25561 0.3 0.7 36876 4036 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.16 -i /depots/var/archive-urls.16
root 25562 0.4 0.7 36876 4020 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.17 -i /depots/var/archive-urls.17
root 25563 0.3 0.7 36876 4024 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.18 -i /depots/var/archive-urls.18
root 25564 0.3 0.7 36876 4068 tty1 S 01:11 0:02 wget --no-cache --limit-rate0m -t 5 -r -N -l inf -o /depots/var/archive-log.19 -i /depots/var/archive-urls.19
root 25632 0.0 0.1 7832 892 pts/0 S+ 01:20 0:00 grep -E (apt-mirror|wget)


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 ?

Voilà, merci d'avance pour votre aide.

--
François Lafont
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #25460202
Francois Lafont , dans le message
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
Le #25462812
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
Nicolas George
Le #25462852
Francois Lafont , dans le message
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 #25462872
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
Damien Wyart
Le #25463072
* 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
Le #25463092
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
Le #25463782
* 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
Publicité
Poster une réponse
Anonyme