Forum Programmation.shell attendre la fin d'un processus créé depuis un autre shell

Posté par minitchoup le 08 février 2009 à 17:59.

Étiquettes : aucune

fév.

2009

Donc la commande 'wait' ne fait pas l'affaire, la salope, puisqu'elle ne permet de considérer que les processus enfants!

j'ouvre deux terminaux A & B:

Depuis A :



> sleep 60 &

[1] 11808

> wait 11808     # génial, j'attends

Depuis B :



> wait 11808

bash: wait: pid 11808 is not a child of this shell

caramba!!!
je ne voudrais pas être obligé à scruter en permanence l'état du processus dont j'attends qu'il se termine.

Merci pour vos réponses.

# Worksforme

Posté par fcartegnie le 08 février 2009 à 19:05. Évalué à -4.

Moi ça marche.

sleep 60& wait $!
[1] 8050
[1]+ Done sleep 60
# Re

Posté par riba le 08 février 2009 à 19:10. Évalué à 1.

> Merci pour vos réponses.

C'est quoi la question? (exactement)

( a priori j'entrevois une solution avec des locks exclusif mais je sais pas ce que tu veux faire... )
- [^] # Re: Re
  
  Posté par minitchoup le 08 février 2009 à 20:07. Évalué à 2.
  
  je cherche à savoir comment m'y prendre pour attendre la terminaison d'un processus, sachant que ce processus n'est pas un processus enfant (fils) du shell où je veut faire l'attente.
  
  dans un shell je lance 'xclock'. dans un autre shell (mais pas sous-shell du premier) je veux faire un wait $(PID_XCLOCK). marche pas! comment faire?
  - [^] # Re: Re
    
    Posté par riba le 08 février 2009 à 20:27. Évalué à 4.
    
    ok.
    
    wait est un builtin shell qui dit au shell de lancer le syscall wait (ou waitpid), donc tu ne peux attendre que les fils du shell.
    
    Il y a plein de solutions a ton probleme:
    - ton process tient un lock exculsif sur un fichier (via fcntl), et tu peux donc attendre avec la demande du meme lock;
    - ton process tient une socket, et tu peux donc attendre avec un select, ca revient un peu au meme;
    - tu t'attaches carrement au processus cible, via ce que tu veux (gdb, ..., le plus simple: strace). L'attache tombera avec la fin du process cible:
    shell A
    #sleep 60
    shell B
    #strace -q -e '' -s 0 -p `pidof sleep` && echo 'finit!'
# Use Sed

Posté par Rémi Birot-Delrue le 08 février 2009 à 23:44. Évalué à 4.

$ sed 's/salope/fourbe/g'
# fichier lock ?

Posté par NeoX le 09 février 2009 à 00:01. Évalué à 3.

dans le shell A, tu crees un fichier /var/lock/mon_fichier_lock au debut de l'execution, que tu effaceras en fin d'execution de A

dans le shell B tu regardes s'il y a ce fichier lock
s'il y est alors le process A est en train de tourner, il faut attendre.

s'il n'y est pas, tu peux t'executer.

evidemment cela peut fonctionner dans l'autre sens
mettre le fichier lock à la fin de A, pour que B accepte de se lancer uniquement si le fichier de lock existe
- [^] # Re: fichier lock ?
  
  Posté par totof2000 le 09 février 2009 à 13:07. Évalué à 3.
  
  Cette solution a un petit inconvénient : si ton process A se vautre sans avoir le temps de supprimer le fichier ....
  
  Pour pallier : indique le No de process dans le fichier et lorsque le process B se lance, il vérifie que le process A tourne toujours.
  - [^] # Re: fichier lock ?
    
    Posté par NeoX le 09 février 2009 à 14:17. Évalué à 2.
    
    exactement,
    je n'avais pas pensé au vautrage de A.
    
    mais du coup ce n'est plus /var/lock/mon_verrouA
    mais plutot /var/run/mon_appliA
    
    avec le pid dedans
  - [^] # Re: fichier lock ?
    
    Posté par Dabowl_92 le 09 février 2009 à 15:09. Évalué à 1.
    
    ou alors, si on a la main sur le code du process A, on peut traper les signaux et supprimer le verrou automatiquement.
    
    Exemple pour un script :
    
    trap 'rm verrou' 2
    
    On supprime le verrou si on reçoit le signal 2 (SIGINT), à noter qu'on peut le faire sur d'autres signaux, sauf bien sûr SIGKILL, mais bon on utilise rarement le SIGKILL quand même :)
    - [^] # Re: fichier lock ?
      
      Posté par Octabrain le 09 février 2009 à 15:32. Évalué à 1.
      
      Attention cependant avec "trap", ici tu ne fais que supprimer le verrou en cas de SIGINT, le programme ne se terminera pas. Avec "trap", il faut quitter explicitement.
      - [^] # Re: fichier lock ?
        
        Posté par Dabowl_92 le 09 février 2009 à 15:38. Évalué à 1.
        
        oui absolument, j'ai oublié de le préciser.
# while

Posté par Octabrain le 09 février 2009 à 14:43. Évalué à 2.

while kill -0 $LEPID; do sleep 1; done
# la scrutation c'est pas top

Posté par minitchoup le 09 février 2009 à 20:36. Évalué à 2.

merci pour toutes vos réponses.

les problèmes de la scrutation périodique :
1/ si la vérification a lieu toutes les secondes, il peut dans le pire cas se passer une seconde entre la terminaison du processus et le moment où elle est détectée
2/ le process de surveillance consomme du CPU inutilement (d'autant plus que la période de scrutation est courte)

Pour cela je trouve la solution suggérée par 'rb14' plus intéressante (le coup du strace). J'attends une solution qui mette en oeuvre une spécificité du noyau (sorte de wait). peut être que je jetterai un œil sur le code du strace.
- [^] # Re: la scrutation c'est pas top
  
  Posté par gaaaaaAab le 09 février 2009 à 22:09. Évalué à 2.
  
  mouais ... c'est dommage que de toutes les solutions proposées, tu t'arrêtes juste sur la plus crade :)
  
  accessoirement, je ne suis pas du tout persuadé qu'attacher un strace à ton process sera moins couteux qu'une surveillance régulière :D
  
  Autre solution, faire lancer ton process par un démon (qui connaitra donc le statut du fils en permanence), et prévoir un protocol de com avec ce démon pour que d'autres process puissent l'interroger sur l'état du fils en passant par des IPCs.
  Par contre, en terme de dèv, c'est plus couteux que les autres solutions proposées ... (il faut p-e utiliser autre chose que du shell ?)
  
  Evidemment, le postulat de départ est que le code de ce que tu veux lancer (le fils de ton premier shell) n'est pas sous ton contrôle, sinon, il "suffit" de multithreader le fils et de permettre à d'autres processus de s'enregistrer auprès de lui pour être notifié de la terminaison via des IPCs.
  - [^] # Re: la scrutation c'est pas top
    
    Posté par gaaaaaAab le 09 février 2009 à 22:32. Évalué à 1.
    
    je précise, pour prévenir les interprétations erronées :
    1/ les autres propositions de rb14 ne sont pas crades
    2/ la solution que je propose est juste une vague ébauche pour signaler qu'il serait possible de mettre en place un méchanisme qui permettrait d'être notifié de la terminaison du processus fils d'un autre processus. Dans la pratique, ça vaut pas le coup. N'importe quelle solutions en shell, quitte à faire un peu de polling, sera sûrement plus adaptée !
    - [^] # Re: la scrutation c'est pas top
      
      Posté par riba le 09 février 2009 à 23:56. Évalué à 2.
      
      > 1/ les autres propositions de rb14 ne sont pas crades
      
      ah quand même...
      
      Même strace -e '' n'est pas si intrusif que ça en fait, vu qu'il ne fait pratiquement rien (s'attacher uniquement à exit(), mais faut vérifier).
      C'est la solution qui ne suppose rien sur le process, et sans polling (car ç'est mal), ni rebond via fichier ou socket.
      
      C'est vrai que son probleme est quand même bizarre, tout contrôler d'en haut et faire un waitpid() est beaucoup plus logique.
      - [^] # Re: la scrutation c'est pas top
        
        Posté par gaaaaaAab le 10 février 2009 à 01:49. Évalué à 1.
        
        en fait, tout dépend du contexte dans lequel tu t'en sers.
        
        Dans cas là, strace n'est pas utilisé pour tracer les appels systèmes, mais pour profiter d'un effet de bord : la détection de la fin du process. C'est typiquement du hack ;-)
        Mais le fait de viser l'effet de bord, ça rend la solution trompeuse pour des lecteurs non avertis, et du coup, ça réduit la maintenabilité de la solution.
        ça va bien pour un script fait chez soi, mais si c'est dans un contexte pro, il faut documenter ça, tout en sachant que de toute façon, personne lit la doc :D
        C'est dans ce sens là que je trouve ça un peu crade.
        
        bon, après, y a aussi des problèmes de portabilité sur d'autre *nix mais comme on est sur *linux*fr, on en parle pas (un troll se cache peut-être dans cette phrase ;-)
        
        Après, c'est vrai que strace avec l'option -e'' (je vais pas faire mon malin, je la connaissais pas :), c'est probablement moins gourmand que le classique strace sans option qui te raconte la vie du noyau de la première lib dynamique pas trouvée 150 fois pendant le chargement du process aux 3 misérables appels systèmes dont ton code est "vraiment" responsable =)
        Faudrait bencher de toute façon (comme pour toute les questions de perf)
        
        sinon, le polling, c'est mal, mais ça peut être un compromis acceptable (comme d'utiliser strace ;-) là, y a que minitchoup qui sait vraiment ce qu'il veut faire ...
        
        [^] # Re: la scrutation c'est pas top
        
        Posté par riba le 10 février 2009 à 14:39. Évalué à 1.
        
        > mais si c'est dans un contexte pro
        
        vu le ton du journal ("la salope","caramba!!!",..) ça ressemble pas trop à un developpement pro.
        
        C'est vrai que sortir strace juste pour voir le exit() est un peu bourrin, je l'avoue...
        
        > sinon, le polling, c'est mal, mais ça peut être un compromis acceptable
        
        Jusqu'au jour où tu tombes sur le cas : ton process cible meurt et un nouveau chope le même pid juste derrière...
        Mon experience: le polling n'est jamais fiable à 100%, il y aura toujours un cas tordu que tu n'auras pas prévu.
        
        [^] # Re: la scrutation c'est pas top
        
        Posté par minitchoup le 10 février 2009 à 20:52. Évalué à 1.
        
        Non effectivement, la problématique que je vous ai soumise ne me concerne qu'à titre personnel, mais peut intéresser les curieux... j'espère au passage que le "salope" n'aura choqué personne, même pas Asgeir...
        
        Il est possible, je n'ai pas fait mais j'en suis aussi convaincu, d'écrire (même en bash) un programme de démarrage et de surveillance qui :
        - à son lancement, démarre l'application indiquée
        - envoie dans le pipe désigné un "signal" dès que l'application se termine
        
        avantage :
        - l'application est un processus enfant du shell => le programme peut utiliser un wait
        - le programme "client" qui veut être informé peut se mettre en attente d'un evt sur le pipe sans consommer de CPU (lecture synchrone)/
        
        inconvénient :
        - pour l'instant, seul un/le client peut être informé de la terminaison de l'application
        - c'est dingue (je trouve) d'en arriver là. Le besoin me parait simple et légitime. Mais bon je ne prétendrait pas avoir exploré toutes les solutions...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.