Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

tuer un processus avec signal 9, elegant ?

3 réponses
Avatar
matlerouge
Bonjour

avec gmplayer, si on lance 1 fichier video, et qu'on en lance un
deuxieme, il y a deux session de gmplayer en meme temps, ce qui n'est
pas tres pratique. Et ce n'est pas tres pratique non plus de fermer une
session a la main avant de demarer l'autre.

J'ai donc fais un petit script bash qui suprime automatiquement
l'ancienne session de mplayer avant de lancer la suivante. Le pb c'est
que je suis obliger de killer l'ancien par un "kill -9 $PID" car un avec
un simple kill $PID, gmplayer envoi une fenetre de dialogue en disant "g
recu un signal 15" ce qui n'est pas tres pratique.

Donc est-ce que faire un kill -9 regulierement sur un processus peut
etre mauvais (peut etre qu'il y aura, par exemple, une acumulation de
petits fichiers temporaire creer par mplayer qu'il n'aura pas le temps
d'effacer)

merci

3 réponses

Avatar
Rakotomandimby (R12y) Mihamina
( Sun, 12 Dec 2004 00:07:31 +0100 ) matlerouge :
Donc est-ce que faire un kill -9 regulierement sur un processus peut
etre mauvais (peut etre qu'il y aura, par exemple, une acumulation de
petits fichiers temporaire creer par mplayer qu'il n'aura pas le temps
d'effacer)


Je ne sais pas pour mplayer precisement mais:

Un player est juste censé lire un fichier et a moins de faire la lecture
avec un decodage/encodage a la volée qui necessite la lecture/ecriture
sur un fichier tmp, normalement il ne crée pas de fichier tmp. Si un
player devait faire cela, je pense que ca saccaderait a mort. Ce sont
plutot les decodeurs/encodeurs/transcodeurs qui font cela.

De plus, quand bien meme il utiliserait un fichier tmp, il le placerait
dans /tmp (si il est bien codé :-) ). Et /tmp se fait purger
regulierement.

Donc pour parler de mplayer, je dirai que ... ce n'est pas trop grave.

Pour d'autres programmes, ca peut etre grave. Peut-etre... peut-etre pas...

--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)

Avatar
Nicolas George
matlerouge wrote in message <41bb6f9c$0$9786$:
Donc est-ce que faire un kill -9 regulierement sur un processus peut
etre mauvais (peut etre qu'il y aura, par exemple, une acumulation de
petits fichiers temporaire creer par mplayer qu'il n'aura pas le temps
d'effacer)


En l'occurence, selon de device vidéo que tu utilises, tu peux te retrouver
avec une mauvaise restauration des paramètres. En particulier, avec les
drivers X11 et compagnie (Xv, etc.), les paramètres de screen saver et de
DPMS ne seront pas correctement rétablis. Donc après un kill -9, tu pars
faire des courses pendant trois heures, et quand tu reviens, tu te rends
compte que l'écran est resté allumé tout ce temps, ce qui est un peu du
gaspillage.

Avec d'autres drivers, il peut éventuellement se passer pire, si mplayer
fait des accès plus bas niveau.

Avatar
no_spam
On Sun, 12 Dec 2004 00:07:31 +0100, matlerouge wrote:

Bonjour

avec gmplayer, si on lance 1 fichier video, et qu'on en lance un
deuxieme, il y a deux session de gmplayer en meme temps, ce qui n'est
pas tres pratique. Et ce n'est pas tres pratique non plus de fermer une
session a la main avant de demarer l'autre.

J'ai donc fais un petit script bash qui suprime automatiquement
l'ancienne session de mplayer avant de lancer la suivante. Le pb c'est
que je suis obliger de killer l'ancien par un "kill -9 $PID" car un avec
un simple kill $PID, gmplayer envoi une fenetre de dialogue en disant "g
recu un signal 15" ce qui n'est pas tres pratique.


Il gère peut-être un autre signal (SIGHUP ?) pour se terminer ?


Donc est-ce que faire un kill -9 regulierement sur un processus peut
etre mauvais (peut etre qu'il y aura, par exemple, une acumulation de
petits fichiers temporaire creer par mplayer qu'il n'aura pas le temps
d'effacer)


Un player vidéo n'est pas censé avoir besoin de fichiers temporaires.
Mais effectivement il vaut mieux éviter les kill -9, autant que possible.