J'ai quelques scripts que j'ai bricolés, lancés via cron.
J'aimerais ajouter à une vérification, si le script est déjà lancé, ça
quitte silencieusement. Comme certaines étapes du script sont longues
(compressions de données par exemple), je souhaite éviter que la tâche
cron suivante ne relance le même script si le précédent est toujours en
cours.
Au fait, je précise que cet exemple n'est pas seulement indicatif, il tourne en production depuis maintenant 8 ans, sur un serveur Postfix, avec possiblement 50 spam^Wmails concurrents. La section critique est l'écriture des logs - du log unique, tout le reste est parallélisable. Jamais aucun problème.
Sauf quand je ponds une erreur de syntaxe en upgradant le script :-)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Xavier <xavier@groumpf.org> wrote:
Ex (en sh POSIX)
Au fait, je précise que cet exemple n'est pas seulement indicatif, il
tourne en production depuis maintenant 8 ans, sur un serveur Postfix,
avec possiblement 50 spam^Wmails concurrents. La section critique est
l'écriture des logs - du log unique, tout le reste est parallélisable.
Jamais aucun problème.
Sauf quand je ponds une erreur de syntaxe en upgradant le script :-)
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Au fait, je précise que cet exemple n'est pas seulement indicatif, il tourne en production depuis maintenant 8 ans, sur un serveur Postfix, avec possiblement 50 spam^Wmails concurrents. La section critique est l'écriture des logs - du log unique, tout le reste est parallélisable. Jamais aucun problème.
Sauf quand je ponds une erreur de syntaxe en upgradant le script :-)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Che Averell
Gilles Pion écrit :
De la question initiale, ou il est question de cron, on peut, sans trop de risque de se tromper, déduire que le script en question est lancé par une unique crontab à intervalles réguliers, et dans ce cas pas de risque de provoquer ce genre de "collision" (qui implique deux exécutions *strictements* simultanées).
Oui, je suis d'accord, mais autant donner les limites des méthodes utilisées, des fois que quelqu'un reprenne le script et l'utilise dans un autre contexte. Les choses qui vont sans le dire vont toujours mieux en le disant.
Sinon, j'ai déjà vu des scripts cron lancés simultanément : cron avait été lancé deux fois...
Gilles Pion <nosuchuser@nosuchdomain.com> écrit :
De la question initiale, ou il est question de cron, on peut, sans
trop de risque de se tromper, déduire que le script en question est
lancé par une unique crontab à intervalles réguliers, et dans ce cas
pas de risque de provoquer ce genre de "collision" (qui implique
deux exécutions *strictements* simultanées).
Oui, je suis d'accord, mais autant donner les limites des méthodes
utilisées, des fois que quelqu'un reprenne le script et l'utilise dans
un autre contexte. Les choses qui vont sans le dire vont toujours
mieux en le disant.
Sinon, j'ai déjà vu des scripts cron lancés simultanément : cron avait
été lancé deux fois...
De la question initiale, ou il est question de cron, on peut, sans trop de risque de se tromper, déduire que le script en question est lancé par une unique crontab à intervalles réguliers, et dans ce cas pas de risque de provoquer ce genre de "collision" (qui implique deux exécutions *strictements* simultanées).
Oui, je suis d'accord, mais autant donner les limites des méthodes utilisées, des fois que quelqu'un reprenne le script et l'utilise dans un autre contexte. Les choses qui vont sans le dire vont toujours mieux en le disant.
Sinon, j'ai déjà vu des scripts cron lancés simultanément : cron avait été lancé deux fois...
Nicolas George
Xavier, dans le message <1jz8mvw.d6i5necl9co0N%, a écrit :
C'est nettement plus facile à insérer dans un script que lockf(1) qui demande une commande en argument et l'éxécute.
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois gérer tous les scénarios d'échec à la main.
Xavier, dans le message <1jz8mvw.d6i5necl9co0N%xavier@groumpf.org>, a
écrit :
C'est nettement plus facile à insérer dans un script que lockf(1) qui
demande une commande en argument et l'éxécute.
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois
gérer tous les scénarios d'échec à la main.
Xavier, dans le message <1jz8mvw.d6i5necl9co0N%, a écrit :
C'est nettement plus facile à insérer dans un script que lockf(1) qui demande une commande en argument et l'éxécute.
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois gérer tous les scénarios d'échec à la main.
xavier
Nicolas George <nicolas$ wrote:
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois gérer tous les scénarios d'échec à la main.
Certes, mais dans le man de lockf je ne vois pas que la commande puisse être une fonction définie dans le script. Ce qui limite son intérêt, je trouve.
Mais je ne demande qu'à être démenti.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Nicolas George <nicolas$george@salle-s.org> wrote:
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois
gérer tous les scénarios d'échec à la main.
Certes, mais dans le man de lockf je ne vois pas que la commande puisse
être une fonction définie dans le script. Ce qui limite son intérêt, je
trouve.
Mais je ne demande qu'à être démenti.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois gérer tous les scénarios d'échec à la main.
Certes, mais dans le man de lockf je ne vois pas que la commande puisse être une fonction définie dans le script. Ce qui limite son intérêt, je trouve.
Mais je ne demande qu'à être démenti.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Nicolas George
Xavier, dans le message <1jz9l4c.1a9zq467gqdxkN%, a écrit :
Certes, mais dans le man de lockf je ne vois pas que la commande puisse être une fonction définie dans le script.
Évidemment. Si ça ne te parait pas évident que ce n'est pas possible, tu ne devrais pas chercher à écrire des scripts compliqués.
Ce qui limite son intérêt, je trouve.
Bof. La commande est prévue pour être appelée en amont du script. Il suffit de couper le script en deux fichiers : un fichier qui pose le verrou et appelle le second.
Si on tient à tout faire en un seul fichier, on peut faire joujou avec l'environnement ou un paramètre.
Xavier, dans le message <1jz9l4c.1a9zq467gqdxkN%xavier@groumpf.org>, a
écrit :
Certes, mais dans le man de lockf je ne vois pas que la commande puisse
être une fonction définie dans le script.
Évidemment. Si ça ne te parait pas évident que ce n'est pas possible, tu ne
devrais pas chercher à écrire des scripts compliqués.
Ce qui limite son intérêt, je
trouve.
Bof. La commande est prévue pour être appelée en amont du script. Il suffit
de couper le script en deux fichiers : un fichier qui pose le verrou et
appelle le second.
Si on tient à tout faire en un seul fichier, on peut faire joujou avec
l'environnement ou un paramètre.
Xavier, dans le message <1jz9l4c.1a9zq467gqdxkN%, a écrit :
Certes, mais dans le man de lockf je ne vois pas que la commande puisse être une fonction définie dans le script.
Évidemment. Si ça ne te parait pas évident que ce n'est pas possible, tu ne devrais pas chercher à écrire des scripts compliqués.
Ce qui limite son intérêt, je trouve.
Bof. La commande est prévue pour être appelée en amont du script. Il suffit de couper le script en deux fichiers : un fichier qui pose le verrou et appelle le second.
Si on tient à tout faire en un seul fichier, on peut faire joujou avec l'environnement ou un paramètre.
Erwan David
(Xavier) écrivait :
Nicolas George <nicolas$ wrote:
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois gérer tous les scénarios d'échec à la main.
Certes, mais dans le man de lockf je ne vois pas que la commande puisse être une fonction définie dans le script. Ce qui limite son intérêt, je trouve.
Mais je ne demande qu'à être démenti.
Dans un script j'utilise dotlockfile. (PS : attention lockf, flock ou les locks poss par fcntl peuvent avoir un comportement étrange sur NFS).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
xavier@groumpf.org (Xavier) écrivait :
Nicolas George <nicolas$george@salle-s.org> wrote:
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois
gérer tous les scénarios d'échec à la main.
Certes, mais dans le man de lockf je ne vois pas que la commande puisse
être une fonction définie dans le script. Ce qui limite son intérêt, je
trouve.
Mais je ne demande qu'à être démenti.
Dans un script j'utilise dotlockfile.
(PS : attention lockf, flock ou les locks poss par fcntl peuvent avoir
un comportement étrange sur NFS).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Du coup, c'est aussi nettement plus facile de se planter, parce que tu dois gérer tous les scénarios d'échec à la main.
Certes, mais dans le man de lockf je ne vois pas que la commande puisse être une fonction définie dans le script. Ce qui limite son intérêt, je trouve.
Mais je ne demande qu'à être démenti.
Dans un script j'utilise dotlockfile. (PS : attention lockf, flock ou les locks poss par fcntl peuvent avoir un comportement étrange sur NFS).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
LIEB Simon
denist a écrit :
Bonjour,
J'ai quelques scripts que j'ai bricolés, lancés via cron. J'aimerais ajouter à une vérification, si le script est déjà lancé, ça quitte silencieusement. Comme certaines étapes du script sont longues (compressions de données par exemple), je souhaite éviter que la tâche cron suivante ne relance le même script si le précédent est toujours en cours.
Merci d'avance
Bonjour,
En utilisant la commande pidof (si disponible) ? Elle retourne la liste des pids correspondant à une commande :
$ pidof /bin/bash 32589 30703
Et son code de retour est 0 s'il y a au moins un programme trouvé ou 1 s'il n'y en a pas (Voir le man de pidof)
Ensuite tout dépend du shell utilisé, mais en bash un simple test sur le code de retour permettrat de déterminer si la commande est lancé :
pidof /ma/commande > /dev/null if [ $? -eq 1 ]; then # Le script n'est pas en cours d'execution fi
denist a écrit :
Bonjour,
J'ai quelques scripts que j'ai bricolés, lancés via cron.
J'aimerais ajouter à une vérification, si le script est déjà lancé, ça
quitte silencieusement. Comme certaines étapes du script sont longues
(compressions de données par exemple), je souhaite éviter que la tâche
cron suivante ne relance le même script si le précédent est toujours en
cours.
Merci d'avance
Bonjour,
En utilisant la commande pidof (si disponible) ?
Elle retourne la liste des pids correspondant à une commande :
$ pidof /bin/bash
32589 30703
Et son code de retour est 0 s'il y a au moins un programme trouvé ou 1
s'il n'y en a pas (Voir le man de pidof)
Ensuite tout dépend du shell utilisé, mais en bash un simple test sur le
code de retour permettrat de déterminer si la commande est lancé :
pidof /ma/commande > /dev/null
if [ $? -eq 1 ]; then
# Le script n'est pas en cours d'execution
fi
J'ai quelques scripts que j'ai bricolés, lancés via cron. J'aimerais ajouter à une vérification, si le script est déjà lancé, ça quitte silencieusement. Comme certaines étapes du script sont longues (compressions de données par exemple), je souhaite éviter que la tâche cron suivante ne relance le même script si le précédent est toujours en cours.
Merci d'avance
Bonjour,
En utilisant la commande pidof (si disponible) ? Elle retourne la liste des pids correspondant à une commande :
$ pidof /bin/bash 32589 30703
Et son code de retour est 0 s'il y a au moins un programme trouvé ou 1 s'il n'y en a pas (Voir le man de pidof)
Ensuite tout dépend du shell utilisé, mais en bash un simple test sur le code de retour permettrat de déterminer si la commande est lancé :
pidof /ma/commande > /dev/null if [ $? -eq 1 ]; then # Le script n'est pas en cours d'execution fi
