que se passe-t-il si un processus qui a plusieurs process buffers ouverts
(via popen) meurt (*) avant de faire pclose ?
(*) dans les trois cas :
exit(0)
exit(i), i!=0
abort() (ou tout autre signal)
en particulier, est ce que les processus fils sont tués par signaux, ou bien
sont ils détachés du père (puis rattachés à init) en finissant de lire ce
qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce
implementation defined ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
que se passe-t-il si un processus qui a plusieurs process buffers ouverts (via popen) meurt (*) avant de faire pclose ?
(*) dans les trois cas : exit(0) exit(i), i!=0 abort() (ou tout autre signal)
en particulier, est ce que les processus fils sont tués par signaux, ou bien sont ils détachés du père (puis rattachés à init) en finissant de lire ce qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce implementation defined ?
Un peu partout. C'est du B.A.BA unix ;-)
Quand un processus meurt, tous ses file-descriptors ouverts sont fermés. Dans le cas des pipes, les données tamponnées peuvent bien sur être lues. Pour la question des fils, ça dépend du traitement des signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien. Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Il faut voir que popen, exit et abort sont des fonctions de bibliothèque C, et qu'elles sont donc définies en fonction des syscalls unix. Il faut donc soit avoir de l'imagination (pour se douter des primtives unix utilisées), soit du courage (pour télécharger les sources de glibc ou de sa libc favorite et pour les lire).
-- __Pascal Bourguignon__ http://www.informatimago.com/ You're always typing. Well, let's see you ignore my sitting on your hands.
Pierre Habouzit <madcoder@debian.org> writes:
que se passe-t-il si un processus qui a plusieurs process buffers ouverts
(via popen) meurt (*) avant de faire pclose ?
(*) dans les trois cas :
exit(0)
exit(i), i!=0
abort() (ou tout autre signal)
en particulier, est ce que les processus fils sont tués par signaux, ou bien
sont ils détachés du père (puis rattachés à init) en finissant de lire ce
qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce
implementation defined ?
Un peu partout. C'est du B.A.BA unix ;-)
Quand un processus meurt, tous ses file-descriptors ouverts sont
fermés. Dans le cas des pipes, les données tamponnées peuvent bien
sur être lues. Pour la question des fils, ça dépend du traitement des
signaux et des groupes de processus. Dans le cas d'exit(), il ne se
passe donc rien. Dans le cas d'un signal, ça dépend si les processus
fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Il faut voir que popen, exit et abort sont des fonctions de
bibliothèque C, et qu'elles sont donc définies en fonction des
syscalls unix. Il faut donc soit avoir de l'imagination (pour se
douter des primtives unix utilisées), soit du courage (pour
télécharger les sources de glibc ou de sa libc favorite et pour les
lire).
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
que se passe-t-il si un processus qui a plusieurs process buffers ouverts (via popen) meurt (*) avant de faire pclose ?
(*) dans les trois cas : exit(0) exit(i), i!=0 abort() (ou tout autre signal)
en particulier, est ce que les processus fils sont tués par signaux, ou bien sont ils détachés du père (puis rattachés à init) en finissant de lire ce qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce implementation defined ?
Un peu partout. C'est du B.A.BA unix ;-)
Quand un processus meurt, tous ses file-descriptors ouverts sont fermés. Dans le cas des pipes, les données tamponnées peuvent bien sur être lues. Pour la question des fils, ça dépend du traitement des signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien. Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Il faut voir que popen, exit et abort sont des fonctions de bibliothèque C, et qu'elles sont donc définies en fonction des syscalls unix. Il faut donc soit avoir de l'imagination (pour se douter des primtives unix utilisées), soit du courage (pour télécharger les sources de glibc ou de sa libc favorite et pour les lire).
-- __Pascal Bourguignon__ http://www.informatimago.com/ You're always typing. Well, let's see you ignore my sitting on your hands.
Nicolas George
Pascal Bourguignon wrote in message :
signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien.
C'est un peu rapide, cf. plus bas.
Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Ça dépend aussi, et surtout, de si le signal est envoyé au processus lui-même (cas le plus fréquent de très loin, sauf signaux générés par le terminal ; en particulier, cas de abort), auquel cas les fils continuent comme si de rien était, ou au groupe, auquel cas ils reçoivent peut-être le signal aussi, selon s'ils sont détachés.
Et dans les deux cas, s'ajoute la subtilité des sessions : si le process qui se termine est le session leader, ça peut provoquer des envois de SIGHUP aux autres process de la session.
Pascal Bourguignon wrote in message
<87u0e2537g.fsf@thalassa.informatimago.com>:
signaux et des groupes de processus. Dans le cas d'exit(), il ne se
passe donc rien.
C'est un peu rapide, cf. plus bas.
Dans le cas d'un signal, ça dépend si les processus
fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Ça dépend aussi, et surtout, de si le signal est envoyé au processus
lui-même (cas le plus fréquent de très loin, sauf signaux générés par le
terminal ; en particulier, cas de abort), auquel cas les fils continuent
comme si de rien était, ou au groupe, auquel cas ils reçoivent peut-être le
signal aussi, selon s'ils sont détachés.
Et dans les deux cas, s'ajoute la subtilité des sessions : si le process qui
se termine est le session leader, ça peut provoquer des envois de SIGHUP aux
autres process de la session.
signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien.
C'est un peu rapide, cf. plus bas.
Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Ça dépend aussi, et surtout, de si le signal est envoyé au processus lui-même (cas le plus fréquent de très loin, sauf signaux générés par le terminal ; en particulier, cas de abort), auquel cas les fils continuent comme si de rien était, ou au groupe, auquel cas ils reçoivent peut-être le signal aussi, selon s'ils sont détachés.
Et dans les deux cas, s'ajoute la subtilité des sessions : si le process qui se termine est le session leader, ça peut provoquer des envois de SIGHUP aux autres process de la session.
Pierre Habouzit
Nicolas George wrote:
Pascal Bourguignon wrote in message :
signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien.
C'est un peu rapide, cf. plus bas.
Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Ça dépend aussi, et surtout, de si le signal est envoyé au processus lui-même (cas le plus fréquent de très loin, sauf signaux générés par le terminal ; en particulier, cas de abort), auquel cas les fils continuent comme si de rien était, ou au groupe, auquel cas ils reçoivent peut-être le signal aussi, selon s'ils sont détachés.
Et dans les deux cas, s'ajoute la subtilité des sessions : si le process qui se termine est le session leader, ça peut provoquer des envois de SIGHUP aux autres process de la session.
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même.
merci -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Nicolas George wrote:
Pascal Bourguignon wrote in message
<87u0e2537g.fsf@thalassa.informatimago.com>:
signaux et des groupes de processus. Dans le cas d'exit(), il ne se
passe donc rien.
C'est un peu rapide, cf. plus bas.
Dans le cas d'un signal, ça dépend si les processus
fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Ça dépend aussi, et surtout, de si le signal est envoyé au processus
lui-même (cas le plus fréquent de très loin, sauf signaux générés par le
terminal ; en particulier, cas de abort), auquel cas les fils continuent
comme si de rien était, ou au groupe, auquel cas ils reçoivent peut-être
le signal aussi, selon s'ils sont détachés.
Et dans les deux cas, s'ajoute la subtilité des sessions : si le process
qui se termine est le session leader, ça peut provoquer des envois de
SIGHUP aux autres process de la session.
ok, bref, tout ca pour dire que si je veux que les process fils soient tués
sans avoir le temps de finir, alors il ne faut pas que j'utilise popen,
mais que je fasse mes fork/exec moi même.
merci
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien.
C'est un peu rapide, cf. plus bas.
Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
Ça dépend aussi, et surtout, de si le signal est envoyé au processus lui-même (cas le plus fréquent de très loin, sauf signaux générés par le terminal ; en particulier, cas de abort), auquel cas les fils continuent comme si de rien était, ou au groupe, auquel cas ils reçoivent peut-être le signal aussi, selon s'ils sont détachés.
Et dans les deux cas, s'ajoute la subtilité des sessions : si le process qui se termine est le session leader, ça peut provoquer des envois de SIGHUP aux autres process de la session.
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même.
merci -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Nicolas George
Pierre Habouzit wrote in message <4385706c$0$1786$:
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même.
Tu peux envoyer un signal au process group de ton propre process pour les tuer tous d'un coup sans avoir à connaître leur PID.
Pierre Habouzit wrote in message
<4385706c$0$1786$626a14ce@news.free.fr>:
ok, bref, tout ca pour dire que si je veux que les process fils soient tués
sans avoir le temps de finir, alors il ne faut pas que j'utilise popen,
mais que je fasse mes fork/exec moi même.
Tu peux envoyer un signal au process group de ton propre process pour les
tuer tous d'un coup sans avoir à connaître leur PID.
Pierre Habouzit wrote in message <4385706c$0$1786$:
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même.
Tu peux envoyer un signal au process group de ton propre process pour les tuer tous d'un coup sans avoir à connaître leur PID.
Stephane Chazelas
On Thu, 24 Nov 2005 00:04:04 +0100, Pierre Habouzit wrote: [...]
en particulier, est ce que les processus fils sont tués par signaux, ou bien sont ils détachés du père (puis rattachés à init) en finissant de lire ce qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce implementation defined ?
On Thu, 24 Nov 2005 00:04:04 +0100, Pierre Habouzit wrote:
[...]
en particulier, est ce que les processus fils sont tués par signaux, ou bien
sont ils détachés du père (puis rattachés à init) en finissant de lire ce
qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce
implementation defined ?
On Thu, 24 Nov 2005 00:04:04 +0100, Pierre Habouzit wrote: [...]
en particulier, est ce que les processus fils sont tués par signaux, ou bien sont ils détachés du père (puis rattachés à init) en finissant de lire ce qu'il reste sur leur stdin ?
L'information n'est pas dans popen(3). Est-ce normé qqpart ? est-ce implementation defined ?
On Thu, 24 Nov 2005 00:55:47 +0100, Pascal Bourguignon wrote: [...]
Quand un processus meurt, tous ses file-descriptors ouverts sont fermés. Dans le cas des pipes, les données tamponnées peuvent bien sur être lues.
Pas forcement,
Si elles sont tamponees par le pipe, oui, si elle sont tamponnees par stdio et que le pipe est plein, non.
Pour la question des fils, ça dépend du traitement des signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien. Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
???
Dans le cas d'exit, il se passe des choses, justement. detaché du pere ne veut pas dire grand chose.
Si le process est un controlling process (en gros le chef de session qui a ouvert le terminal en premier), alors exit(3) tue (par un SIGHUP) le job (process group) en foreground. En general, il n'y a guere que des shells qui soient des controlling processes.
Si la mort du processus cause le fait que le process group soit orphelin, en gros si ce processus est un chef de group, alors les membres du groupes se prendront un SIGHUP si l'un d'entre eux est suspendu au moment du exit().
Mais dans les deux cas, c'est exit(3) qui fait ca.
-- Stephane
On Thu, 24 Nov 2005 00:55:47 +0100, Pascal Bourguignon wrote:
[...]
Quand un processus meurt, tous ses file-descriptors ouverts sont
fermés. Dans le cas des pipes, les données tamponnées peuvent bien
sur être lues.
Pas forcement,
Si elles sont tamponees par le pipe, oui, si elle sont
tamponnees par stdio et que le pipe est plein, non.
Pour la question des fils, ça dépend du traitement des
signaux et des groupes de processus. Dans le cas d'exit(), il ne se
passe donc rien. Dans le cas d'un signal, ça dépend si les processus
fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
???
Dans le cas d'exit, il se passe des choses, justement. detaché
du pere ne veut pas dire grand chose.
Si le process est un controlling process (en gros le chef de
session qui a ouvert le terminal en premier), alors exit(3) tue
(par un SIGHUP) le job (process group) en foreground. En
general, il n'y a guere que des shells qui soient des
controlling processes.
Si la mort du processus cause le fait que le process group soit
orphelin, en gros si ce processus est un chef de group, alors
les membres du groupes se prendront un SIGHUP si l'un d'entre
eux est suspendu au moment du exit().
Mais dans les deux cas, c'est exit(3) qui fait ca.
On Thu, 24 Nov 2005 00:55:47 +0100, Pascal Bourguignon wrote: [...]
Quand un processus meurt, tous ses file-descriptors ouverts sont fermés. Dans le cas des pipes, les données tamponnées peuvent bien sur être lues.
Pas forcement,
Si elles sont tamponees par le pipe, oui, si elle sont tamponnees par stdio et que le pipe est plein, non.
Pour la question des fils, ça dépend du traitement des signaux et des groupes de processus. Dans le cas d'exit(), il ne se passe donc rien. Dans le cas d'un signal, ça dépend si les processus fils se sont "détachés" du père (voir setpgid, setpgrp, etc).
???
Dans le cas d'exit, il se passe des choses, justement. detaché du pere ne veut pas dire grand chose.
Si le process est un controlling process (en gros le chef de session qui a ouvert le terminal en premier), alors exit(3) tue (par un SIGHUP) le job (process group) en foreground. En general, il n'y a guere que des shells qui soient des controlling processes.
Si la mort du processus cause le fait que le process group soit orphelin, en gros si ce processus est un chef de group, alors les membres du groupes se prendront un SIGHUP si l'un d'entre eux est suspendu au moment du exit().
Mais dans les deux cas, c'est exit(3) qui fait ca.
-- Stephane
Stephane Chazelas
On Thu, 24 Nov 2005 08:49:29 +0100, Pierre Habouzit wrote: [...]
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même. [...]
Ca ne changera rien.
Avec les pipes, en general, ca se passe bien. Le fait qu'un pipe soit fermé a un bout fait en general que le processus a l'autre bout se termine (soit parce qu'il voit une "fin de fichier" s'il lit, soit parce qu'il se prend un SIGPIPE, s'il ecrit).
Si tu veux que tes fils meurent quand tu meurt, tue-les au moment ou tu meurs.
-- Stephane
On Thu, 24 Nov 2005 08:49:29 +0100, Pierre Habouzit wrote:
[...]
ok, bref, tout ca pour dire que si je veux que les process fils soient tués
sans avoir le temps de finir, alors il ne faut pas que j'utilise popen,
mais que je fasse mes fork/exec moi même.
[...]
Ca ne changera rien.
Avec les pipes, en general, ca se passe bien. Le fait qu'un pipe
soit fermé a un bout fait en general que le processus a l'autre
bout se termine (soit parce qu'il voit une "fin de fichier" s'il
lit, soit parce qu'il se prend un SIGPIPE, s'il ecrit).
Si tu veux que tes fils meurent quand tu meurt, tue-les au
moment ou tu meurs.
On Thu, 24 Nov 2005 08:49:29 +0100, Pierre Habouzit wrote: [...]
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même. [...]
Ca ne changera rien.
Avec les pipes, en general, ca se passe bien. Le fait qu'un pipe soit fermé a un bout fait en general que le processus a l'autre bout se termine (soit parce qu'il voit une "fin de fichier" s'il lit, soit parce qu'il se prend un SIGPIPE, s'il ecrit).
Si tu veux que tes fils meurent quand tu meurt, tue-les au moment ou tu meurs.
-- Stephane
Stephane Chazelas
On Thu, 24 Nov 2005 12:16:24 +0000 (UTC), Nicolas George wrote:
Pierre Habouzit wrote in message <4385706c$0$1786$:
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même.
Tu peux envoyer un signal au process group de ton propre process pour les tuer tous d'un coup sans avoir à connaître leur PID.
Euh, ca peut tuer aussi des parents a soit, ca.
-- Stephane
On Thu, 24 Nov 2005 12:16:24 +0000 (UTC), Nicolas George wrote:
Pierre Habouzit wrote in message
<4385706c$0$1786$626a14ce@news.free.fr>:
ok, bref, tout ca pour dire que si je veux que les process fils soient tués
sans avoir le temps de finir, alors il ne faut pas que j'utilise popen,
mais que je fasse mes fork/exec moi même.
Tu peux envoyer un signal au process group de ton propre process pour les
tuer tous d'un coup sans avoir à connaître leur PID.
On Thu, 24 Nov 2005 12:16:24 +0000 (UTC), Nicolas George wrote:
Pierre Habouzit wrote in message <4385706c$0$1786$:
ok, bref, tout ca pour dire que si je veux que les process fils soient tués sans avoir le temps de finir, alors il ne faut pas que j'utilise popen, mais que je fasse mes fork/exec moi même.
Tu peux envoyer un signal au process group de ton propre process pour les tuer tous d'un coup sans avoir à connaître leur PID.
Euh, ca peut tuer aussi des parents a soit, ca.
-- Stephane
Nicolas George
Stephane Chazelas wrote in message :
Euh, ca peut tuer aussi des parents a soit, ca.
Ah oui, bien vu : il faut penser à initier un nouveau groupe avant.
Stephane Chazelas wrote in message
<slrndobs1p.iim.stephane_chazelas@duey.spider.com>:
Euh, ca peut tuer aussi des parents a soit, ca.
Ah oui, bien vu : il faut penser à initier un nouveau groupe avant.
