Ha et sinon une crontab pour lancer 4320 fois par jour une commande, je pense qu'il est temps de faire un processus qui reste toujours allumé et qui lance la commande avec un sleep time entre chaque itération.

Je n'ose imaginer ton syslog rempli de commandes cron pour rien.

avec >&/dev/null tu ne rediriges pas stderr

Pour rediriger stderr tu devrais avoir 2>&1 > /dev/null

Donc pour moi tes 0.2% sont des erreurs de résolution dns où la commande soit fait une sortie dans stderr soit un return code différent de 0 ou les deux.

my 20 cents

Le 03/12/2021 à 19:07, David Ponzone a écrit :

Fan de casse-têtes, puzzles, et autres trucs énervants,

Ceci est pour toi.

Soit une Debian 9.5. Soit un script bash qui est lancé par crontab 1440 fois par jour.

Dans la crontab, le script est lancé ainsi:

*/1 * * * * script >&/dev/null

En fait, je le lance 3 fois par min, avec des params différents, donc 4320 lancements par jour.

Le script appelle un binaire, qui accessoirement fait lors de son exécution un:

fprintf(stderr, "Resolving remote host '%s'... ", remote_host);

Comme stdout et stderr sont redirigés vers /dev/null, crontab ne m’envoie jamais de mail….

….sauf entre 2 et 20 fois par jour, où j’ai la chance de recevoir un mail qui contient:

Resolving remote host ’truc.bidule.fr'... Done.

Donc lors de 0,2% (environ) des exécutions, stderr n’est pas correctement renvoyée vers /dev/null.

Alors moi perso, je suis pas un fan de ce genre d’énigme, surtout si c’est pour découvrir que c’est un truc connu, un bug de bash, ou de la libc sur une Debian 9.5.

Je lance le chrono, il y a des tueurs sur cette liste :)

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/