Discussion :

[Jimmy91]

Bonjour à tous,

J'écris un script en Shell où se trouve une fonction traitement() devant être relancée toutes les minutes. Ma première idée fut la suivante :

Code shell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
while [1]
do
  sleep(60)
  traitement()
done

Mais malheureusement, le traitement() peut prendre du temps et le délai d'une minute entre chaque lancement ne serait plus respecté. Avez-vous une idée sur ce problème s'il vous plaît ? Dois-je lancer traitement dans un thread séparé ou existe-t-il des solutions moins lourdes ?

Merci pour vos réponses !

[kevin254kl]

Bonjour, un chrontab qui lance ton script toutes les minutes ne fonctionne pas?

[gangsoleil]

Comme proposé par Kevin254kl, l'utilisation de la crontab est la bonne solution.

Néanmoins, il faut faire attention aux choses suivantes : tous les chemins doivent être en absolu, et que se passe-t-il si deux exécutions, ou plus, sont lancées en même temps ?

[Jean.Cri1]

Tu peux en effet aussi lancer traitement en tache de fond avec un &

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

traitement() &

apres son appel dans ta boucle
mais avec la meme question : les fonctions traitement peuvent elles s'executer en parellele ?

[ggnore]

Pour ne pas lancer 2 traitements en parallèle, alors que le 1er n'est pas terminé, soit :
- Quand ton script se lance, il écrit dans /var/run/monscript.pid (si le fichier existe déjà, on quitte)
- Quand ton script se lance, il vérifie avec ps, qu'il n'est pas déjà en cours.

[N_BaH]

Bonjour,

le traitement() peut prendre du temps et le délai d'une minute entre chaque lancement ne serait plus respecté

pour résumé :

• soit tu laisses le traitement se terminer, et alors le délai d'une minute n'est pas respecté
• soit tu ne lances pas de traitement concurrent en vérifiant qu'i n'était en cours d'exécution au préalable, et alors le délai d'une minute n'est pas respecté
• soit «c'est bon ! on s'en fout !», et alors gare au bobo

[xian21]

Pour ne pas lancer 2 traitements en parallèle, alors que le 1er n'est pas terminé, soit :
- Quand ton script se lance, il écrit dans /var/run/monscript.pid (si le fichier existe déjà, on quitte)
- Quand ton script se lance, il vérifie avec ps, qu'il n'est pas déjà en cours.

Bonjour,

ayant eu la meme problematique il y a peu de temps ce sujet m'interesse.
Je lance avec un crontab un jar qui realise un long traitement.
J'ai verifie pendant l'execution de celui-ci je ne vois aucune mention de celui-ci ni avec la commande ps ni dans var/run/.
Il y a t il une option speciale a utiliser?

Merci

[xian21]

Bonjour, un chrontab qui lance ton script toutes les minutes ne fonctionne pas?

PS c'est crontab -e

[Didier-T]

Bonjour,

ayant eu la meme problematique il y a peu de temps ce sujet m'interesse.
Je lance avec un crontab un jar qui realise un long traitement.
J'ai verifie pendant l'execution de celui-ci je ne vois aucune mention de celui-ci ni avec la commande ps ni dans var/run/.
Il y a t il une option speciale a utiliser?

Merci

Bonjour,
Peut-être devrais tu utiliser une commande avec sudo, personnellement j'aime bien pgrep

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
sudo pgrep -f nom_du_script

[BufferBob]

pour ce genre de problématique la manière la plus fiable de procéder est de créer un verrou (lock), souvent sous la forme d'un fichier

au début du programme on vérifie si le fichier existe;
- si oui c'est qu'une autre tache est déjà en train de s’exécuter (modulo quelques cas limites), donc on termine le programme
- si non, alors on crée le fichier, une fois le traitement fini on efface le fichier et on termine le programme

en revanche les fichiers dans /var/run/*pid sont des cas à part, ils ne sont pas obligatoirement créés (comprendre: rien ne le garanti), et il vaut mieux traiter la pose des verrous directement dans le programme

penser également que si la machine crash pour une raison ou une autre il est préférable que le fichier de lock ne reste pas au prochain démarrage, le répertoire /tmp/ est en général vidé à chaque démarrage de la machine, ce qui en fait un bon candidat pour stocker les verrous temporaires, on trouve d'ailleurs couramment des fichiers comme /tmp/.X0-lock dedans

[Escapetiger]

On peut rajouter le cas où le programme est terminé de façon abrupte, un kill SIGKILL par exemple. Il est utile alors de combiner le nom du fichier lock avec le PID du process et de vérifier si ledit process est encore actif.

[gangsoleil]

pour ce genre de problématique la manière la plus fiable de procéder est de créer un verrou (lock), souvent sous la forme d'un fichier

Si le verrou est une bonne idée, le fichier est malheureusement une mauvaise implémentation, trop souvent utilisée. Si ton programme plante, ce qui peut arriver même aux meilleurs, ton fichier reste présent sur le disque, et les traitements suivants ne seront pas lancés.

Le plus intéressant est l'utilisation de sockets, et particulièrement de socket Unix : tu ouvres une socket sur le port XXXXX dans ton programme : tant qu'il est vivant, la socket reste ouverte, et tu peux supprimer la socket proprement à la fin. Mais si ton programme plante, le système va automatiquement nettoyer la socket au bout d'un moment (2 minutes de mémoire, mais c'est configurable dans ton programme). Ainsi, tu louperas peut-être une exécution ou deux, mais au moins tu n'auras pas besoin d'une intervention manuelle pour supprimer le fichier.

[Jimmy91]

Bonjour et merci à tous pour vos réponses !

Finalement j'ai choisi d'utiliser la solution de Jean.Cri1. Comme mon traitement revient en boucle infinie, je n'ai pas besoin de vérifier s'il existe encore et un traitement en tâche de fond est exactement ce qu'il me faut. :-)

[jack-ft]

pour ce genre de problématique la manière la plus fiable de procéder est de créer un verrou (lock), souvent sous la forme d'un fichier

au début du programme on vérifie si le fichier existe;
- si oui c'est qu'une autre tache est déjà en train de s’exécuter (modulo quelques cas limites), donc on termine le programme
- si non, alors on crée le fichier, une fois le traitement fini on efface le fichier et on termine le programme

[chipotage]Si on ne fait pas le test et la création en une seule opération indivisible (test and set), il y a toujours la probabilité (quoique très faible) qu'un programme concurrent fasse la même chose au même moment:
- les 2 programmes testent en même temps l'existence du fichier de lock.
- le fichier de lock n'existe pas.
- les 2 programmes tentent de le créer (un seul réussit vraiment).
- les 2 programmes continuent en ayant cru l'avoir créé...

Il vaut mieux (si on reste sur la solution d'un fichier de lock géré manuellement):
- créer un répertoire (et non un fichier) avec mkdir
- tester le code de retour du mkdir
- si le code retour est différent de 0 (la création a échoué), terminer le programme.
- si le code retour est 0 (la création a réussi), alors continuer.
[/chipotage]