Forum Programmation.shell Signaux

Posté par  .
Étiquettes : aucune
0
22
fév.
2006
Bonjour;

Je cherche à comprendre deux points de la gestion des signaux en shell :

1 - pourquoi le script suivant peut-être interrompu "proprement" lorsqu'il est exécuté en foreground dans une console (par exemple avec le Ctrl+C, SIGINT) alors que depuis une console tierce, l'envoie d'un signal SIGINT est ignoré ? Est-ce lié à la gestion des tty ?

2 - pourquoi, enfin, un SIGKILL lancé depuis une autre console résulte dans l'arrêt du seul /bin/sh (le sleep restant en arrière plan, et fils du PID 1) ?



#!/bin/sh

sleep 3600


En recherchant la ou les explications de ces comportements, je souhaiterais surtout trouver un moyen pour interrompre "récursivement" tous les processus fils d'un processus déterminé (script shell), comme, me semble-t'il, lorsque ce dernier recoît un Ctrl+C.

Bien sûr, le "sleep" peut être remplacé par une ou plusieurs autres commandes externes; un "ls -R /" par exemple. Le comportement décrit semble répandu : sur Linux, Solaris & Cygwin (W2K), et avec bash, ksh ou csh.

Merci pour vos réponses ou pistes éventuelles.

  • # I go to sleep

    Posté par  (site web personnel) . Évalué à 2.

    D'après moi, ce qui se passe quand tu fais un Ctrl+C c'est interrompre le sleep

    Donc faire un script peut interrompre le premier sleep mais pas le deuxième (à tester). Sinon, c'est que le Ctrl+C se fait sur tous les processuce, jusqu'à ce que l'application rende la main

    #!/bin/sh

    sleep 3600
    sleep 3600

    Quand tu fais un kill, tu envois le kill au script et donc à Sh. Les enfants n'étant pas tué.

    Regarde par un man kill, s'il n'y a pas une option qui permet de tuer recursivement (il me semble avoir déjà vu ça quelque part).

    • [^] # Re: I go to sleep

      Posté par  . Évalué à 1.

      Non, je pense que le Ctrl+C tue bien le sh. L'exemple avec les deux sleep le montre bien d'ailleurs.

      Le man ne dit rien sur la récursivité.

      Merci pour ta réponse en tout cas.

  • # groupe de processus

    Posté par  . Évalué à 2.

    En fait, quand tu fais un Ctrl-C, sigint n'est pas envoyé à un processus, mais à groupe de processus (PGID) par ton shell ; alors que toi, tu fais ton kill sur un PID (donc un seul processus). En faisant kill -INT -PID tu devrais obtenir un comportement ressemblant (note le - avant le PID).

    C'est le shell qui change le pgid et le masque de signaux avant de lancer tes commandes en background ou en foreground. C'est pour cela que tu as un comportement différent suivant comment ta commande est lancée. Libre à toi de rechanger ce masque de signaux dans l'applicatif lancé (cf. la commande trap pour les shell scripts ; en particulier trap - SIGINT remet l'action par défaut sur réception de sigint, soit mourir :) ).
    Bon, y aurait vraiment beaucoup à dire sur les signaux,pid,pgid, je te conseille de te documenter sur les signaux unix en général histoire de comprendre les aspects théoriques (désolé, j'ai pas de liens à te filer, mais ça doit pouvoir se trouver sur le net, je pense).

    • [^] # Re: groupe de processus

      Posté par  . Évalué à 1.

      Yes !
      Merci pour ces éclaircissements; la notion de groupe de processes m'était assez obscure jusqu'à maintenant.

      Je pense avoir compris : dans un programme C, utiliser le setpgid() dans le fils me permet de le signaler avec un -PID - ce qui entraine à première vue le comportement que j'attendais.

      J'imagine que c'est ce que fais le shell pour les nouveaux processes en mode interactif, par exemple, et que c'est ce comportement que tu décrivais.

      Merci encore !

Suivre le flux des commentaires

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