[Résolu] Terminer un processus qui semble ignorer SIGTERM

Arbiel · Le 14/03/2018, à 23:28

Bonsoir à tous

[Edit]
L'effet de SIGTERM est légèrement différé (pour une raison que j'ignore), ce que je n'ai pas su interpréter du fait de la brièveté du texte lu; par contre l'effet de SIGKILL est immédiat
[/Edit]

Le script que je mets au point lit le texte d'un message avec la commande suivante

pico2wave -l fr-FR -w /tmp/message.wav "${msg}"; (play /tmp/message.wav &>/dev/null &)

Je souhaite stopper cette lecture à l'instant que je juge approprié. Malheureusement la commande play semble insensible au message SIGTERM comme le montre le test ci-dessous

remi@remi-Vostro-3550:~$ function pl () { local msg=${1};
>  pid=$(pico2wave -l fr-FR -w /tmp/message.wav "${msg}"; (play /tmp/message.wav &>/dev/null | echo $! &););
> prop=$(ps -p ${pid} -o comm=);
> pkill --signal SIGTERM ${prop}
> pgrep -a -u ${USER} ${prop} 
> }
remi@remi-Vostro-3550:~$ pl "Texte du message à lire"
12478 play /tmp/message.wav
remi@remi-Vostro-3550:~$

pid=$(pico2wave -l fr-FR -w /tmp/message.wav "${msg}"; (play /tmp/message.wav &>/dev/null | echo $! &);); lance la lecture en asynchrone et retourne le pid dans la variable pid
prop=$(ps -p ${pid} -o comm=); renvoie le nom du processus;
pkill --signal SIGTERM ${prop}; est supposée terminer le processus
pgrep -a -u ${USER} ${prop}; montre que le processus (play /tmp/message.wav) est toujours actif

Merci d'avance à quiconque pourra m'indiquer comment terminer le processus play par une ligne de commande.

Arbiel

Dernière modification par Arbiel (Le 16/03/2018, à 10:35)

Watael · Le 15/03/2018, à 00:02

salut,

bein...c'est qu'elle est mal foutue ta fonction.
d'abord, c'est function OU (), sinon c'est un pléonasme.
ensuite

pl()
{
   local msg="$1"
   pico2wave -l fr-FR -w /tmp/message.wav "$msg"
   play /tmp/message.wav &>/dev/null &
   echo $!
}
pid2kill=$(pl "text 2 read")

pas testé...

enfin, arrêtez de mettre des accolades aux variables qui ne sont pas concaténées à du texte !

« le pr[ochain] que j'attrape [...] je le fous à la poooorte... avec un rapport... de chez Monsieur Vaudois »

MicP · Le 15/03/2018, à 05:32

C'est promis, je ferais attention.

Arbiel · Le 15/03/2018, à 11:17

Bonjour

@Watael

Merci pour tes commentaires. Je conçois que les pléonasmes te déplaisent. Je ne sais pas expliquer d'où me vient cette fâcheuse habitude. Il s'agit probablement du fait que tous les interpréteurs de commandes ne suivent pas la même règle. Après avoir recopié dans un script une fonction écrite "qqch ()", je crois avoir dû ajouter "function", sans prendre la peine de retirer les (), pour que l'interpréteur que j'utilisais alors l'accepte.

Dans ce que je lis sur le forum, me choquent beaucoup plus les fautes d'orthographe, les fautes de français, l'usage abusif d'anglicismes, le détournement de la signification de termes tels que "excessivement" à la place de "extrêmement", "hors" au lieu de "or", même si je pratique moi-même ce que je condamne, en bon donneur de leçons.

Je dois avouer être tellement rétrograde que, dans la vie courante, je dois me retenir pour ne pas faire remarquer à qui me dit "Excusez-moi" que je n'ai à recevoir d'ordre de personne pour excuser ou ne pas excuser mon interlocuteur de sa maladresse.

L'utilisation d'accolades, même inutiles, pour entourer le nom des variables me semble importante pour faciliter leur recherche, et je ne dérogerai pas à cette habitude, qui ne devrait pourtant pas te gêner au point d'en exiger le retrait. Tu sais comme moi qu'exiger des autres qu'ils se comportent comme soi-même peut pousser aux pires excès.

Enfin, tout cela n'a guère d'importance, comme l'évoque MicP.

Revenons-en, si tu veux bien, à mon problème, qui ne découle absolument pas de la manière, même désastreuse, dont j'écris mes commandes. L'envoi de la commande kill au processus play ne provoque pas son arrêt, ce que montre parfaitement bien la commande pgrep qui la suit.

D'où mon interrogation : comment, dans un script bash, arrêter play ?

Et si tu as la moindre idée de la manière de faire, je te remercie d'avance de bien vouloir m'en faire part, même si je n'adhère pas totalement à tes principes.

Cordialement

Arbiel

Dernière modification par Arbiel (Le 15/03/2018, à 11:20)

credenhill · Le 15/03/2018, à 11:34

hello
envoyer SIGKILL (kill -9) ?

maxire · Le 15/03/2018, à 12:30

Salut,

Pourquoi utiliser pkill, à priori tu connais le numéro de processus de play $pid ou ${pid}, accolades ou non ce n'est pas important.

kill $pid

devrait le faire.
Tu peux également tenter:

pkill --ns $pid play

Edit:
Ce que j'ai testé faute d'utiliser pico2wave.

[aspire7730z@asus-arch The falling]$ pid=$( touch toto;(play  -q Track\ 1.flac | echo $! &);)
[aspire7730z@asus-arch The falling]$ echo $pid
8039
[aspire7730z@asus-arch The falling]$ ps
  PID TTY          TIME CMD
 7281 pts/2    00:00:00 bash
 8039 pts/2    00:00:00 play
 8045 pts/2    00:00:00 ps
[aspire7730z@asus-arch The falling]$ kill -s 15 $pid
[aspire7730z@asus-arch The falling]$ ps
  PID TTY          TIME CMD
 7281 pts/2    00:00:00 bash
 8057 pts/2    00:00:00 ps
[aspire7730z@asus-arch The falling]$ pid=$( touch toto;(play  -q Track\ 1.flac | echo $! &);)
[aspire7730z@asus-arch The falling]$ ps
  PID TTY          TIME CMD
 7281 pts/2    00:00:00 bash
 8063 pts/2    00:00:00 play
 8067 pts/2    00:00:00 ps
[aspire7730z@asus-arch The falling]$ pkill --ns $pid play
[aspire7730z@asus-arch The falling]$ ps
  PID TTY          TIME CMD
 7281 pts/2    00:00:00 bash
 8070 pts/2    00:00:00 ps
[aspire7730z@asus-arch The falling]$

Dernière modification par maxire (Le 15/03/2018, à 13:16)

MicP · Le 15/03/2018, à 14:04

Arbiel a écrit :

…comme l'évoque MicP.…

C'était sincère car j'ai moi aussi la même mauvaise habitude,
et c'est vrai qu'elle permet aussi, à la relecture, de mieux repérer ses variables.

=======
Et pour les anglicismes, j'utilise trop souvent mounter et mountage à la place de monter et montage,
mais comme j'ai remarqué que ça choque un peu certains, je vais essayer d'éviter ça aussi.

Ce qui me gène aussi, c'est l'utilisation du mot dossier à la place de répertoire,
et quand certains disent monter un disque ou une partition,
mais bon, je n'ai jamais été très bon en orthographe, je suis assez limité en vocabulaire,
et j'ai d'énormes difficultés à rédiger mes messages, c'est pour ça que je les modifie souvent plus tard.

=======
J'apprécie beaucoup la qualité de vos messages.

Dernière modification par MicP (Le 15/03/2018, à 14:08)

Watael · Le 15/03/2018, à 15:47

le truc avec un signe dollar devant, c'est une variable !
ça devrait quand même vous aider à les repérer, non ?

et, utilisez un éditeur qui supporte la coloration syntaxique,
ça ira tout de suite mieux.

Arbiel · Le 15/03/2018, à 19:57

Bonsoir

Je vous remercie tous pour l'intérêt que vous avez porté à mon problème.

Si je ne m'explique pas pourquoi le processus play est encore actif après pkill, comme le montre pgrep dans la fonction pl que j'ai présentée au point #1, je pense que je me suis fortement trompé dans l'interprétation des tests que j'ai exécutés.

Le message que j'utilisais était très court et il est fort probable qu'il était contenu en intégralité dans le tampon de sortie vers les haut-parleurs (dans la carte son ?). J'ai refait des tests avec de la musique. Vos diverses suggestions fonctionnent parfaitement.

@Watael

Il est vrai que la présence du $ devant un identifiant permet de le caractériser comme une variable. L'utilisation d'un éditeur avec coloration syntaxique apporte également une aide indéniable dans la recherche visuelle des variables.

Mais tu ne peux nier que la présence d'accolades facilite les recherches automatiques. Il peut m'arriver d'utiliser dans un même script par exemple "lg" et "lg_chaine" ou "nb" et "nb_param". Les accolades rendent inutile l'utilisation d'une expression régulière pour éliminer les faux positifs.

Cela étant, je comprends bien que dans la fonction pl que j'ai présentée au point #1 la présence de ces accolades est complètement inutile. Mais je me suis établi la règle d'utiliser cette notation, règle que j'avoue transgresser parfois seul dans mon coin, mais que j'essaie de respecter sur le forum.

@MicP
Merci. Tu m'as fait plaisir.

@MicP, Watael
Mais faut-il me vouvoyer pour autant, même s'il est vrai, comme le chante Serge Reggiani, que "la femme qui est dans mon lit n'a plus vingt ans depuis longtemps" ? L'utilisation du tutoiement ne me paraît en rien irrespectueux, et je l'avais compris comme une habitude largement partagée sur le forum.

Arbiel

Watael · Le 15/03/2018, à 20:10

c'est comme souligner un mot en gras et clignotant...

et, ce n'est pas toi que je vouvoie, c'est tous ceux qui font pareil.

sinon, niveau zigouillage de process, on en est où ?

Arbiel · Le 15/03/2018, à 23:18

Bonsoir

Je n'ai pas suffisamment réfléchi au fonctionnement probable de play avant d'en conclure qu'il ignorait le signal SIGTERM. Le comportement que j'ai incorrectement déduit de mes tests provenait de la brièveté du texte à diffuser, entièrement contenu dans le premier flux envoyé vers la carte son.

Après plus ample réflexion, il me semble tout à fait logique qu'après avoir envoyé un flux vers la carte son, play s'endorme en attendant d'être réveillé pour l'envoi du flux suivant. Le signal SIGTERM envoyé par la commande kill est ainsi destiné à un processus en sommeil et n'est pas immédiatement traité. La commande pgrep qui suit immédiatement cette commande kill trouve tout à fait logiquement play, encore en attente de réveil, dans la liste des processus.

Au total, play traite correctement le signal SIGTERM, et tout fonctionne correctement.

Merci encore à vous tous pour votre aide.

Arbiel

Watael · Le 15/03/2018, à 23:32

hmmm, pas convaincu.

fais afficher un très gros fichier par cat, tant que le fichier n'est pas fini d'être lu, cat fait défiler le contenu du fichier à l'écran, et est en cours d'exécution. play c'est pareil, dans les haut-parleurs.

Arbiel · Le 16/03/2018, à 00:38

Je me trompe peut-être, mais je ne dois pas être loin de la réalité.

J'appuie mes déductions sur le fait que lorsque play porte sur un morceau de musique, le délai entre l'envoi du signal d'arrêt et l'arrêt effectif de la musique est parfaitement perceptible. La carte audio sert indubitablement de tampon, et la musique s'arrête (probablement) lorsque le tampon est vide et non à l'envoi du signal. Peut-être faudrait-il envoyer un signal de réveil puis le signal d'arrêt pour constater si pgrep trouve encore ou ne trouve plus play dans la liste des processus, et voir l'impact sur la musique.

Par contre, avec cat, il semble que l'arrêt de l'affichage soit immédiat. À vrai dire je ne sais pas si mon PC dispose ou non d'une carte vidéo. Voilà ce que j'ai extrait de lshw

lshw a écrit :

*-display
description: VGA compatible controller
produit: 2nd Generation Core Processor Family Integrated Graphics Controller
fabriquant: Intel Corporation
identifiant matériel: 2
information bus: pci@0000:00:02.0
version: 09
bits: 64 bits
horloge: 33MHz
fonctionnalités: vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0
ressources: irq:52 mémoire:f6400000-f67fffff mémoire:d0000000-dfffffff portE/S:f000(taille=64)
…
*-multimedia
description: Audio device
produit: 6 Series/C200 Series Chipset Family High Definition Audio Controller
fabriquant: Intel Corporation
identifiant matériel: 1b
information bus: pci@0000:00:1b.0
version: 05
bits: 64 bits
horloge: 33MHz
fonctionnalités: bus_master cap_list
configuration: driver=snd_hda_intel latency=0
ressources: irq:55 mémoire:f7c00000-f7c03fff

Pour mettre en évidence l'absence de délai entre l'envoi du signal d'arrêt à cat et son arrêt effectif, j'ai utilisé deux terminaux.

Sur le premier j'ai fait afficher à l'écran un texte de plusieurs dizaines de milliers de ligne, et je l'ai fait suivre de la diffusion d'un morceau de musique.

Sur le deuxième terminal, j'ai passé la commande kill $(pidof cat) que je l'ai fait suivre de la diffusion du même morceau de musique.

L'écart éventuel entre les deux morceaux de musique était imperceptible à l'oreille, de même que l'arrêt du premier. Cet écart est inférieur aux quelque 50 ou 60 millisecondes de signal audio que l'oreille peut détecter.

Watael · Le 16/03/2018, à 00:56

je ne sais pas si mon PC dispose ou non d'une carte vidéo

tu aurais pu le déduire de ce que tu vois ou non autre chose que ton reflet sur l'écran.

Arbiel · Le 16/03/2018, à 10:46

Watael a écrit :

hmmm, pas convaincu.

En fin de compte, moi non plus.

Lors de me tests, je n'avais pas suivi le conseil de

credenhill a écrit :

envoyer SIGKILL (kill -9) ?

Avec SIGKILL, l'arrêt de la diffusion est immédiat. J'ai refait le test du #14 avec "play un morceau de musique" et en utilisant SIGKILL au lieu de SIGTERM. J'ai obtenu le même résultat qu'avec "cat fichier texte volumineux" et SIGTERM : aucun décalage entre les musiques n'est perceptible, ni l'arrêt de l'un d'entre eux.

Je ne sais ainsi absolument pas pourquoi l'impact de SIGTERM est légèrement différé. Mes hypothèses sur l'effet éventuel de la carte audio sont tout à fait contestables.

Je pense que la discussion peut être définitivement fermée.

Merci encore à tous pour votre aide.

Arbiel

Dernière modification par Arbiel (Le 16/03/2018, à 10:53)

Watael · Le 16/03/2018, à 13:56

parce que SIGTERM effectue quelques vérification pour fermer correctement tout ce qui est lié au process, alors que SIGKILL est moins respectueux. (?)

Arbiel · Le 16/03/2018, à 23:41

En quelque sorte, c'est la différence entre "terminer" et "exterminer"

Watael · Le 17/03/2018, à 03:43

                        Exterminate!
                       /
                  ___
          D>=G==='   '.
                |======|
                |======|
            )--/]IIIIII]
               |_______|
               C O O O D
              C O  O  O D
             C  O  O  O  D
             C__O__O__O__D
            [_____________]

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 14/03/2018, à 23:28

[Résolu] Terminer un processus qui semble ignorer SIGTERM

#2 Le 15/03/2018, à 00:02

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#3 Le 15/03/2018, à 05:32

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#4 Le 15/03/2018, à 11:17

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#5 Le 15/03/2018, à 11:34

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#6 Le 15/03/2018, à 12:30

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#7 Le 15/03/2018, à 14:04

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#8 Le 15/03/2018, à 15:47

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#9 Le 15/03/2018, à 19:57

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#10 Le 15/03/2018, à 20:10

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#11 Le 15/03/2018, à 23:18

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#12 Le 15/03/2018, à 23:32

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#13 Le 16/03/2018, à 00:38

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#14 Le 16/03/2018, à 00:56

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#15 Le 16/03/2018, à 10:46

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#16 Le 16/03/2018, à 13:56

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#17 Le 16/03/2018, à 23:41

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

#18 Le 17/03/2018, à 03:43

Re : [Résolu] Terminer un processus qui semble ignorer SIGTERM

Pied de page des forums