Salut,
Je bosse sur une interface pour un script. J'aimerais savoir s'il y a un moyen de récupérer la liste des processus lancé par les processus fils de mon interface. Sachant qu'un shéma est plus parlant, le voilou :

Donc, actuellement si je quitte l'interface (dvddumpui), le script (dvddump) quitte normalement. MAIS dvdauthor et streamdvd sont adoptés par init et continue leur boulot. Ce sont donc ces 2 processus que j'aimerais quitter pour bien nettoyer le système...
 
La seule solution que je vois est d'exécuter "ps" et de tout traiter à la main... Existe-t-il une solution plus facile à mettre en oeuvre ?

Ces bonnes vieilles commandes que sont ps, grep et cut vont surement t'être utiles.
 
Fais des man sur ps et cut pour avoir les options qui vont bien.
Couple ça avec un for (pour ksh, foreach pour csh) et tu auras tout ce dont tu as besoin en 5 lignes de code.
 
Note qu'il y a un truc qui va pas si les fils ne se tuent pas à la mort du père. Ils sont lancés par des nohup ?

 
La notion de "petit-fils" n'existe pas sous Unix (et apparentés). C'est pour ça qu'un processus orphelin est adopté par "init" (et non par son grand-père comme cela pourrait être imaginé ailleurs)
 
Sinon pstree existe aussi sous Linux.

C'est bien ce que je craignais...
J'aurais aimer coder le nettoyage en C et éviter d'avoir un script à fournir en plus, pas par obligation, juste le challenge du tout C/C++
pstree m'a tout l'air d'être le complément parfait cependant.
Merci pour vos réponses
 
Edit:

Non, ils sont lancés tout ce qu'il y a de plus normalement. Et si, en continuant sur l'exemple précédent, j'envoie SIGTERM à dvdauthor, streamdvd est adopté aussi par init et je dois aussi lui envoyer SIGTERM manuellement.

Yees    
Je pensais que ça allait être bien plus dur en fait    
 
Voilà la solution que j'utilise :
script cleanup-process avec en argument le pid du processus parent (que je détruis dans mon appli) :

 
et je l'apelle depuis mon interface avec:

 
J'aimerais savoir pour l'appel à system, s'il est préférable d'apeller avec "sh script" ou "./script" ? Et si le premier est dépendant du type de shell installé ? En ce qui concerne la sécurité, y a-t-il quelque chose à prévoir ?

Utilises plutôt "-ne" pour comparer des numériques...

Quasiment pareil. En appelant "sh script"; tu demandes au shell d'interpréter "script". En appelant directement "./script", ben tu demandes à exécuter "script" mais comme c'est un shell, le shell va l'interpréter
Juste que si tu fais "sh script", t'as pas besoin de mettre le droit "x" pour "script"
 

Cette question pose un point capital en matière de portabilité. Si tu écris un script, tu ne l'écris pas que pour toi. Mais si tu l'écris en "csh" ben il faut que les autres soient en csh pour l'utiliser. OR, les autres sont à priori en n'importe quoi. Pour solutionner le pb, tu dois indiquer dans ton script quel est l'interpréteur utilisé. Cela se fait en début par la ligne

 
par exemple, si tu écris un script en csh, tu dois mettre en début

 
et si tu écris un script en bash, tu dois mettre en début

 
Ainsi, quel que soit l'environnement de travail de celui qui exécute ton script, celui-ci sera interprété par le binaire inscrit dans cette fameuse ligne => ton script est portable et tu ne te préoccupes pas de l'endoit où tu l'installes
 

Euh... que veux tu dire en "sécurité" ?

ok, merci
 

Je l'ai écris en choississant /bin/bash comme interpréteur. Apparemment, il a l'air d'être présent sur la majorité des postes. Mais si quelqu'un n'a pas bash installé, y a-t-il moyen de se rabattre sur un autre interpréteur ?
 
 

En posant la question, je me suis dit que c'était peut-être un peu idiot. Mais dans le livre que j'utilise (prog  systeme en C sous Linux de C. Blaess), il y a un exemple d'appel :

qui peut permettre une attaque s'il est lancé avec un PATH modifié (d'où l'intérêt du ./ par rapport au sh), et (ce que j'avais lu un peu rapidement) si le programme appelant est setuid root. Comme ce n'est pas le cas de mon programme, la question ne se pose sans doute pas

Le set uid bit, c'est mal.

Pour être certain de la compatibilité descendante (ton programme marchera même sur des systèmes plus vieux) tu dois l'écrire en Bourne Shell (sans les subtilités ksh ou bash) et mettre "#!/bin/sh". Ton script fonctionnera partout.
 

Exact. Le programme sera exécuté avec les droits de l'utilisateur qui le lance. C'est pour cela qu'il est inutile de développer un virus sous Linux => il n'infectera que l'utilisateur qui le lance => d'où la remarque d'Elmoricq
 

Le fait de mettre un répertoire devant le nom du script ("./script" ou
"/usr/bin/script" ) inhibe la variable PATH ce qui est une garantie supplémentaire. De plus, c'est pour éviter ce genre de traquenard que les bouquins de sécurité disent d'éviter de mettre "." dans le PATH de root et, surtout, si on le met quand-même, de ne jamais le mettre en premier.

Ca y est les modif sont faîtes. Merci des infos