J'ai un petit script perl qui realise une commande systeme.
J'aimerais rajouter une fonctionnalite mais je n'ai aucune idee
de comment la faire :
Il arrive que le script soit lancer a 2 ou 3x casi simultanement.
J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs
fois, qu'il attende quelques secondes (5 a 10s) que tous les
"lancement" ce calme (du style pas de nouveau lancement depuis
5s alors il peut continuer) et il execute la commande.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sébastien Cottalorda
Bonjour,
J'ai un petit script perl qui realise une commande systeme.
J'aimerais rajouter une fonctionnalite mais je n'ai aucune idee de comment la faire :
Il arrive que le script soit lancer a 2 ou 3x casi simultanement. J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs fois, qu'il attende quelques secondes (5 a 10s) que tous les "lancement" ce calme (du style pas de nouveau lancement depuis 5s alors il peut continuer) et il execute la commande.
comment je pourrais faire ?
Merci d'avance Salut,
Tu as plusieurs possibilités:
dans une boucle while(1) suivie d'un sleep 5,
1°) Vérifier si une ou plusieurs instances de ta commande système tourne. @ps_ax = `ps axw | grep ton_programme | grep -v grep` ($#ps_ax +1) te donnera le nombre d'instance(s) simultanné(es). L'extraction de la première colonne du tableau @ps_ax te donnera les PID
2°) aulieu de lancer la commande system, fork le programme: - Le père reçoit le PID du fils et peut le gérer, y compris recevoir un signal lorsque ce dernier meure. - Le fils n'a plus qu'à lancer la commande système gràce à exec (et non plus system). Cette dernière méthode est un *peu* plus délicate à mettre au point.
J'espère que cela t'aidera.
Sébastien
Bonjour,
J'ai un petit script perl qui realise une commande systeme.
J'aimerais rajouter une fonctionnalite mais je n'ai aucune idee
de comment la faire :
Il arrive que le script soit lancer a 2 ou 3x casi simultanement.
J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs
fois, qu'il attende quelques secondes (5 a 10s) que tous les
"lancement" ce calme (du style pas de nouveau lancement depuis
5s alors il peut continuer) et il execute la commande.
comment je pourrais faire ?
Merci d'avance
Salut,
Tu as plusieurs possibilités:
dans une boucle while(1) suivie d'un sleep 5,
1°) Vérifier si une ou plusieurs instances de ta commande système tourne.
@ps_ax = `ps axw | grep ton_programme | grep -v grep`
($#ps_ax +1) te donnera le nombre d'instance(s) simultanné(es).
L'extraction de la première colonne du tableau @ps_ax te donnera les PID
2°) aulieu de lancer la commande system, fork le programme:
- Le père reçoit le PID du fils et peut le gérer, y compris recevoir un
signal lorsque ce dernier meure.
- Le fils n'a plus qu'à lancer la commande système gràce à exec (et non
plus system).
Cette dernière méthode est un *peu* plus délicate à mettre au point.
J'ai un petit script perl qui realise une commande systeme.
J'aimerais rajouter une fonctionnalite mais je n'ai aucune idee de comment la faire :
Il arrive que le script soit lancer a 2 ou 3x casi simultanement. J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs fois, qu'il attende quelques secondes (5 a 10s) que tous les "lancement" ce calme (du style pas de nouveau lancement depuis 5s alors il peut continuer) et il execute la commande.
comment je pourrais faire ?
Merci d'avance Salut,
Tu as plusieurs possibilités:
dans une boucle while(1) suivie d'un sleep 5,
1°) Vérifier si une ou plusieurs instances de ta commande système tourne. @ps_ax = `ps axw | grep ton_programme | grep -v grep` ($#ps_ax +1) te donnera le nombre d'instance(s) simultanné(es). L'extraction de la première colonne du tableau @ps_ax te donnera les PID
2°) aulieu de lancer la commande system, fork le programme: - Le père reçoit le PID du fils et peut le gérer, y compris recevoir un signal lorsque ce dernier meure. - Le fils n'a plus qu'à lancer la commande système gràce à exec (et non plus system). Cette dernière méthode est un *peu* plus délicate à mettre au point.
J'espère que cela t'aidera.
Sébastien
Pierrick LE GALL
Bonjour,
Mag writes:
Il arrive que le script soit lancer a 2 ou 3x casi simultanement. J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs fois, qu'il attende quelques secondes (5 a 10s) que tous les "lancement" ce calme (du style pas de nouveau lancement depuis 5s alors il peut continuer) et il execute la commande.
comment je pourrais faire ?
Je n'aime pas trop l'utilisation d'un "ps | grep ma_commande". Si tu sais que ce programme est susceptible d'être lancé plusieurs fois simultanément, que tu souhaites en limiter le nombre d'exécutions et que tu maîtrises le code du programme, je te conseille plutôt de "logger" les débuts et fin d'exécution de ta commande.
Dans un répertoire dédié, à chaque fois que la commande s'exécute, créé un fichier vide nommé <CCYYMMDDHHmmss>-<pid>.waiting. Par exemple 20060828171118-21529.waiting. Ensuite tu listes les fichiers présents dans le répertoire et si tu trouves les conditions requises, tu renommes le fichier en 20060828171125-21529.running (notes l'augmentation de 7 secondes). A la fin de l'exécution, tu supprimes le fichier.
Les conditions de passage de "waiting" à "running", peuvent être :
- aucun autre fichier "waiting"
- moins de 4 fichiers "running" ou plus de 5 secondes depuis le dernier running.
A toi de définir les règles.
Ensuite, il faut prévoir un outil de purge. Par exemple à chaque reboot ou chaque nuit, vidage du répertoire. Ou alors au début de la commande, après avoir listé les fichier présents, considérer que les fichiers plus vieux que X minutes sont à supprimer.
Pour moi ce type de solution est plus propre que le "ps | grep" même si c'est moins souple.
-- Pierrick LE GALL http://le-gall.net/pierrick R&D engineer at Talend, Open data solution http://talend.com
Bonjour,
Mag <mag@lamaldie.fr> writes:
Il arrive que le script soit lancer a 2 ou 3x casi simultanement.
J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs fois,
qu'il attende quelques secondes (5 a 10s) que tous les "lancement" ce
calme (du style pas de nouveau lancement depuis 5s alors il peut
continuer) et il execute la commande.
comment je pourrais faire ?
Je n'aime pas trop l'utilisation d'un "ps | grep ma_commande". Si tu
sais que ce programme est susceptible d'être lancé plusieurs fois
simultanément, que tu souhaites en limiter le nombre d'exécutions et que
tu maîtrises le code du programme, je te conseille plutôt de "logger"
les débuts et fin d'exécution de ta commande.
Dans un répertoire dédié, à chaque fois que la commande s'exécute, créé
un fichier vide nommé <CCYYMMDDHHmmss>-<pid>.waiting. Par exemple
20060828171118-21529.waiting. Ensuite tu listes les fichiers présents
dans le répertoire et si tu trouves les conditions requises, tu renommes
le fichier en 20060828171125-21529.running (notes l'augmentation de 7
secondes). A la fin de l'exécution, tu supprimes le fichier.
Les conditions de passage de "waiting" à "running", peuvent être :
- aucun autre fichier "waiting"
- moins de 4 fichiers "running" ou plus de 5 secondes depuis le dernier
running.
A toi de définir les règles.
Ensuite, il faut prévoir un outil de purge. Par exemple à chaque reboot
ou chaque nuit, vidage du répertoire. Ou alors au début de la commande,
après avoir listé les fichier présents, considérer que les fichiers plus
vieux que X minutes sont à supprimer.
Pour moi ce type de solution est plus propre que le "ps | grep" même si
c'est moins souple.
--
Pierrick LE GALL
http://le-gall.net/pierrick
R&D engineer at Talend, Open data solution http://talend.com
Il arrive que le script soit lancer a 2 ou 3x casi simultanement. J'aimerais faire en sorte qu'il "voit" qu'il est lance plusieurs fois, qu'il attende quelques secondes (5 a 10s) que tous les "lancement" ce calme (du style pas de nouveau lancement depuis 5s alors il peut continuer) et il execute la commande.
comment je pourrais faire ?
Je n'aime pas trop l'utilisation d'un "ps | grep ma_commande". Si tu sais que ce programme est susceptible d'être lancé plusieurs fois simultanément, que tu souhaites en limiter le nombre d'exécutions et que tu maîtrises le code du programme, je te conseille plutôt de "logger" les débuts et fin d'exécution de ta commande.
Dans un répertoire dédié, à chaque fois que la commande s'exécute, créé un fichier vide nommé <CCYYMMDDHHmmss>-<pid>.waiting. Par exemple 20060828171118-21529.waiting. Ensuite tu listes les fichiers présents dans le répertoire et si tu trouves les conditions requises, tu renommes le fichier en 20060828171125-21529.running (notes l'augmentation de 7 secondes). A la fin de l'exécution, tu supprimes le fichier.
Les conditions de passage de "waiting" à "running", peuvent être :
- aucun autre fichier "waiting"
- moins de 4 fichiers "running" ou plus de 5 secondes depuis le dernier running.
A toi de définir les règles.
Ensuite, il faut prévoir un outil de purge. Par exemple à chaque reboot ou chaque nuit, vidage du répertoire. Ou alors au début de la commande, après avoir listé les fichier présents, considérer que les fichiers plus vieux que X minutes sont à supprimer.
Pour moi ce type de solution est plus propre que le "ps | grep" même si c'est moins souple.
-- Pierrick LE GALL http://le-gall.net/pierrick R&D engineer at Talend, Open data solution http://talend.com
Nicolas George
Pierrick LE GALL wrote in message :
- aucun autre fichier "waiting"
Non, ça ne marche pas, il y a une race-condition à ce niveau-là.
Pour que ce schéma marche, il faut que le fichier waiting soit unique et utiliser un mécanisme évitant l'écrasement (O_EXCL, typiquement).
Ensuite, il faut prévoir un outil de purge. Par exemple à chaque reboot ou chaque nuit, vidage du répertoire. Ou alors au début de la commande, après avoir listé les fichier présents, considérer que les fichiers plus vieux que X minutes sont à supprimer.
Bof. C'est le problème avec les mécanismes basés sur le filesystem alors qu'ils ne le devraient pas.
Le posteur original n'est pas très clair sur ce qu'il veut faire (ignorer certains des lancements ? en faire un unique à la fin du traitement précédent ?), mais il y a certainement moyen de le réaliser en utilisant un verrou, ce qui a le mérite d'être lié à un processus, et donc automatiquement nettoyé même si la commande crashe.
Pierrick LE GALL wrote in message <87d5ak28gy.fsf@venus.solar-system>:
- aucun autre fichier "waiting"
Non, ça ne marche pas, il y a une race-condition à ce niveau-là.
Pour que ce schéma marche, il faut que le fichier waiting soit unique et
utiliser un mécanisme évitant l'écrasement (O_EXCL, typiquement).
Ensuite, il faut prévoir un outil de purge. Par exemple à chaque reboot
ou chaque nuit, vidage du répertoire. Ou alors au début de la commande,
après avoir listé les fichier présents, considérer que les fichiers plus
vieux que X minutes sont à supprimer.
Bof. C'est le problème avec les mécanismes basés sur le filesystem alors
qu'ils ne le devraient pas.
Le posteur original n'est pas très clair sur ce qu'il veut faire (ignorer
certains des lancements ? en faire un unique à la fin du traitement
précédent ?), mais il y a certainement moyen de le réaliser en utilisant un
verrou, ce qui a le mérite d'être lié à un processus, et donc
automatiquement nettoyé même si la commande crashe.
Non, ça ne marche pas, il y a une race-condition à ce niveau-là.
Pour que ce schéma marche, il faut que le fichier waiting soit unique et utiliser un mécanisme évitant l'écrasement (O_EXCL, typiquement).
Ensuite, il faut prévoir un outil de purge. Par exemple à chaque reboot ou chaque nuit, vidage du répertoire. Ou alors au début de la commande, après avoir listé les fichier présents, considérer que les fichiers plus vieux que X minutes sont à supprimer.
Bof. C'est le problème avec les mécanismes basés sur le filesystem alors qu'ils ne le devraient pas.
Le posteur original n'est pas très clair sur ce qu'il veut faire (ignorer certains des lancements ? en faire un unique à la fin du traitement précédent ?), mais il y a certainement moyen de le réaliser en utilisant un verrou, ce qui a le mérite d'être lié à un processus, et donc automatiquement nettoyé même si la commande crashe.
