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
Ah oui, bien vu : il faut penser à initier un nouveau groupe avant.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus pouvoir ecrire ou lire sur le terminal sans se prendre des SIGTTOU, SIGTTIN.
-- Stéphane
Pierre Habouzit
Nicolas George wrote:
Stephane Chazelas wrote in message :
Ca ne changera rien.
Si : ça permet de récupérer les PID des fils.
exactement. et du coup de faire des kill ... c'est bête, mais on ne peut pas demander le PID du fils avec popen, ce qui est bien dommage :/ -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Nicolas George wrote:
Stephane Chazelas wrote in message
<slrndobr34.i48.stephane_chazelas@duey.spider.com>:
Ca ne changera rien.
Si : ça permet de récupérer les PID des fils.
exactement. et du coup de faire des kill ...
c'est bête, mais on ne peut pas demander le PID du fils avec popen, ce qui
est bien dommage :/
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
exactement. et du coup de faire des kill ... c'est bête, mais on ne peut pas demander le PID du fils avec popen, ce qui est bien dommage :/ -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Pierre Habouzit
Stephane Chazelas wrote:
2005-11-24, 17:39(+00), 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.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus pouvoir ecrire ou lire sur le terminal sans se prendre des SIGTTOU, SIGTTIN.
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ? -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Stephane Chazelas wrote:
2005-11-24, 17:39(+00), Nicolas George:
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.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus
pouvoir ecrire ou lire sur le terminal sans se prendre des
SIGTTOU, SIGTTIN.
En l'occurence le process serait lancé par un démon, détaché de tout TTY,
donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer
des groupes de process ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Ah oui, bien vu : il faut penser à initier un nouveau groupe avant.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus pouvoir ecrire ou lire sur le terminal sans se prendre des SIGTTOU, SIGTTIN.
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ? -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Pierre Habouzit
Pierre Habouzit wrote:
Stephane Chazelas wrote:
2005-11-24, 17:39(+00), 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.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus pouvoir ecrire ou lire sur le terminal sans se prendre des SIGTTOU, SIGTTIN.
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Pierre Habouzit wrote:
Stephane Chazelas wrote:
2005-11-24, 17:39(+00), Nicolas George:
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.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus
pouvoir ecrire ou lire sur le terminal sans se prendre des
SIGTTOU, SIGTTIN.
En l'occurence le process serait lancé par un démon, détaché de tout TTY,
donc ca ne me dérange pas du tout. Quels sont les appels système pour
gérer des groupes de process ?
ok trouvé, setsid est mon ami.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Ah oui, bien vu : il faut penser à initier un nouveau groupe avant.
Mais ca, ca peut avoir des consequences facheuses, comme ne plus pouvoir ecrire ou lire sur le terminal sans se prendre des SIGTTOU, SIGTTIN.
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Stephane Chazelas
2005-11-24, 21:34(+01), Pierre Habouzit: [...]
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce qu'il faut pour un démon, car ca permet de se detacher d'un terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef de groupe, donc faut faire un fork avant. Faut faire un fork dans tous les cas pour pouvoir etre rataché a init.
Ensuite, tu closes tous tes fds, puis tu fais un setsid (dans le fils, hein), ou plutot dans l'autre sens pour pouvoir afficher un message d'erreur si setsid ne marche pas.
Tu peux fait un fork encore pour ne plus etre un chef de session (car si par malheur tu ouvrais un tty sans O_NOCTTY, ca te ferait un controlling terminal qui pourrait t'envoyer des SIGINT et des SIGTTIN...)
chdir("/") car sinon tu empecherais de demonter un filesystem
dup(dup(open("/dev/null", O_RDWR))) pour avoir des nouveaux stdin/stdout/stderr (car c'est assez dangereux d'avoir ces fds fermés surtout si tu lances un shell comme dans popen qui va pouvoir vouloir ecrire des messages sur stderr, et si le fd 2 a ete utilisé par ton démon pour autre chose...).
Tu peux mettre a jour l'umask aussi parce que tu ne sais pas ce que herites de ton pere.
-- Stéphane
2005-11-24, 21:34(+01), Pierre Habouzit:
[...]
En l'occurence le process serait lancé par un démon, détaché de tout TTY,
donc ca ne me dérange pas du tout. Quels sont les appels système pour
gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce
qu'il faut pour un démon, car ca permet de se detacher d'un
terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef
de groupe, donc faut faire un fork avant. Faut faire un fork
dans tous les cas pour pouvoir etre rataché a init.
Ensuite, tu closes tous tes fds, puis tu fais un setsid (dans le
fils, hein), ou plutot dans l'autre sens pour pouvoir afficher
un message d'erreur si setsid ne marche pas.
Tu peux fait un fork encore pour ne plus etre un chef de
session (car si par malheur tu ouvrais un tty sans O_NOCTTY, ca
te ferait un controlling terminal qui pourrait t'envoyer des
SIGINT et des SIGTTIN...)
chdir("/") car sinon tu empecherais de demonter un filesystem
dup(dup(open("/dev/null", O_RDWR))) pour avoir des nouveaux
stdin/stdout/stderr (car c'est assez dangereux d'avoir ces fds
fermés surtout si tu lances un shell comme dans popen qui va
pouvoir vouloir ecrire des messages sur stderr, et si le fd 2 a
ete utilisé par ton démon pour autre chose...).
Tu peux mettre a jour l'umask aussi parce que tu ne sais pas ce
que herites de ton pere.
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce qu'il faut pour un démon, car ca permet de se detacher d'un terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef de groupe, donc faut faire un fork avant. Faut faire un fork dans tous les cas pour pouvoir etre rataché a init.
Ensuite, tu closes tous tes fds, puis tu fais un setsid (dans le fils, hein), ou plutot dans l'autre sens pour pouvoir afficher un message d'erreur si setsid ne marche pas.
Tu peux fait un fork encore pour ne plus etre un chef de session (car si par malheur tu ouvrais un tty sans O_NOCTTY, ca te ferait un controlling terminal qui pourrait t'envoyer des SIGINT et des SIGTTIN...)
chdir("/") car sinon tu empecherais de demonter un filesystem
dup(dup(open("/dev/null", O_RDWR))) pour avoir des nouveaux stdin/stdout/stderr (car c'est assez dangereux d'avoir ces fds fermés surtout si tu lances un shell comme dans popen qui va pouvoir vouloir ecrire des messages sur stderr, et si le fd 2 a ete utilisé par ton démon pour autre chose...).
Tu peux mettre a jour l'umask aussi parce que tu ne sais pas ce que herites de ton pere.
-- Stéphane
Pierre Habouzit
Stephane Chazelas wrote:
2005-11-24, 21:34(+01), Pierre Habouzit: [...]
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce qu'il faut pour un démon, car ca permet de se detacher d'un terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef de groupe, donc faut faire un fork avant. Faut faire un fork dans tous les cas pour pouvoir etre rataché a init.
hmm, sauf que dans mon cas, mon utilitaire est lancé par postfix, qui surveille mon process, donc ca veut dire que le process va devoir forker et surveiller le fork qui lui fera un setsid. Mais après tout c'est pas très difficile à programmer ... c'est plutot joli même, ca permet de sandboxer mon petit outil. merci !
Ensuite, tu closes tous tes fds, puis tu fais un setsid (dans le [...] que herites de ton pere.
pour le reste je connais déjà. Ce sont les groupes de process que je ne connaissais pas... et je ne comprend pas pourquoi je ne suis jamais tombé dessus, vu comme c'est utile !
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Stephane Chazelas wrote:
2005-11-24, 21:34(+01), Pierre Habouzit:
[...]
En l'occurence le process serait lancé par un démon, détaché de tout
TTY, donc ca ne me dérange pas du tout. Quels sont les appels système
pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce
qu'il faut pour un démon, car ca permet de se detacher d'un
terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef
de groupe, donc faut faire un fork avant. Faut faire un fork
dans tous les cas pour pouvoir etre rataché a init.
hmm, sauf que dans mon cas, mon utilitaire est lancé par postfix, qui
surveille mon process, donc ca veut dire que le process va devoir forker et
surveiller le fork qui lui fera un setsid. Mais après tout c'est pas très
difficile à programmer ... c'est plutot joli même, ca permet de sandboxer
mon petit outil. merci !
Ensuite, tu closes tous tes fds, puis tu fais un setsid (dans le
[...]
que herites de ton pere.
pour le reste je connais déjà. Ce sont les groupes de process que je ne
connaissais pas... et je ne comprend pas pourquoi je ne suis jamais tombé
dessus, vu comme c'est utile !
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce qu'il faut pour un démon, car ca permet de se detacher d'un terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef de groupe, donc faut faire un fork avant. Faut faire un fork dans tous les cas pour pouvoir etre rataché a init.
hmm, sauf que dans mon cas, mon utilitaire est lancé par postfix, qui surveille mon process, donc ca veut dire que le process va devoir forker et surveiller le fork qui lui fera un setsid. Mais après tout c'est pas très difficile à programmer ... c'est plutot joli même, ca permet de sandboxer mon petit outil. merci !
Ensuite, tu closes tous tes fds, puis tu fais un setsid (dans le [...] que herites de ton pere.
pour le reste je connais déjà. Ce sont les groupes de process que je ne connaissais pas... et je ne comprend pas pourquoi je ne suis jamais tombé dessus, vu comme c'est utile !
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Stephane Chazelas
2005-11-25, 09:59(+01), Pierre Habouzit:
Stephane Chazelas wrote:
2005-11-24, 21:34(+01), Pierre Habouzit: [...]
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce qu'il faut pour un démon, car ca permet de se detacher d'un terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef de groupe, donc faut faire un fork avant. Faut faire un fork dans tous les cas pour pouvoir etre rataché a init.
hmm, sauf que dans mon cas, mon utilitaire est lancé par postfix, qui surveille mon process, donc ca veut dire que le process va devoir forker et surveiller le fork qui lui fera un setsid. Mais après tout c'est pas très difficile à programmer ... c'est plutot joli même, ca permet de sandboxer mon petit outil. merci !
A mon avis, si c'est lancé par postfix qui est deja un demon, tu peux simplement faire un setpgid (si postfix ne l'a pas deja fait avant de t'execé), il n'y aura pas de controlling terminal.
-- Stéphane
2005-11-25, 09:59(+01), Pierre Habouzit:
Stephane Chazelas wrote:
2005-11-24, 21:34(+01), Pierre Habouzit:
[...]
En l'occurence le process serait lancé par un démon, détaché de tout
TTY, donc ca ne me dérange pas du tout. Quels sont les appels système
pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce
qu'il faut pour un démon, car ca permet de se detacher d'un
terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef
de groupe, donc faut faire un fork avant. Faut faire un fork
dans tous les cas pour pouvoir etre rataché a init.
hmm, sauf que dans mon cas, mon utilitaire est lancé par postfix, qui
surveille mon process, donc ca veut dire que le process va devoir forker et
surveiller le fork qui lui fera un setsid. Mais après tout c'est pas très
difficile à programmer ... c'est plutot joli même, ca permet de sandboxer
mon petit outil. merci !
A mon avis, si c'est lancé par postfix qui est deja un demon, tu
peux simplement faire un setpgid (si postfix ne l'a pas deja
fait avant de t'execé), il n'y aura pas de controlling terminal.
En l'occurence le process serait lancé par un démon, détaché de tout TTY, donc ca ne me dérange pas du tout. Quels sont les appels système pour gérer des groupes de process ?
ok trouvé, setsid est mon ami.
setsid, c'est pour creer une session, mais typiquement, c'est ce qu'il faut pour un démon, car ca permet de se detacher d'un terminal.
Note qu'on ne peut pas etre chef de session si on est deja chef de groupe, donc faut faire un fork avant. Faut faire un fork dans tous les cas pour pouvoir etre rataché a init.
hmm, sauf que dans mon cas, mon utilitaire est lancé par postfix, qui surveille mon process, donc ca veut dire que le process va devoir forker et surveiller le fork qui lui fera un setsid. Mais après tout c'est pas très difficile à programmer ... c'est plutot joli même, ca permet de sandboxer mon petit outil. merci !
A mon avis, si c'est lancé par postfix qui est deja un demon, tu peux simplement faire un setpgid (si postfix ne l'a pas deja fait avant de t'execé), il n'y aura pas de controlling terminal.
