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 :)
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 http://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/
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.
Le 03/12/2021 à 19:21, Wallace a écrit :
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 http://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/
On vendredi 3 décembre 2021 19:21:12 CET, Wallace wrote:
avec >&/dev/null tu ne rediriges pas stderr
Avec bash, csh, ou zsh, si : https://wiki.bash-hackers.org/syntax/redirection#redirecting_output_and_erro...
Mais avec dash qui est plus posix de base (le /bin/sh par défaut sous debian), c'est interprété comme "script & : >/dev/null"
exemple :
$ echo $SHELL /bin/zsh $ ls good bad &>/dev/null $ $ readlink /bin/sh dash $ /bin/sh $ ls good bad &>/dev/null $ ls: impossible d'accéder à 'good': Aucun fichier ou dossier de ce type ls: impossible d'accéder à 'bad': Aucun fichier ou dossier de ce type
[1] + Done(2) ls good bad $
Donc c'est bien possible que de temps en temps, le script ne passe pas en tache de fond avant la fin du cron et affiche quelque chose
Pour rediriger stderr tu devrais avoir 2>&1 > /dev/null
et ca c'est la syntaxe portable.
On vendredi 3 décembre 2021 19:07:15 CET, David Ponzone wrote:
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
Vincent,
Merci t’es le meilleur, j’ai oublié que crontab utilisait /bin/sh par défaut, comme moi j’utilise bash sur root (et je redéfinis généralement SHELL dans la crontab, mais pas celle-là…) Ce qui est évidemment déroutant, c’est pourquoi 0.2% du temps seulement j’ai un email, alors que le source C envoie tout le temps à stderr, mais tu dois avoir raison, il doit y avoir un truc pas tout à fait atomique/linéaire dans l’exécution.
Effectivement, je vais repasser sur la syntaxe POSIX, rappelée par Wallace, ça sera plus propre.
Je savais que ça irait vite!
Merci
Le 3 déc. 2021 à 19:38, Vincent Tondellier via FRsAG frsag@frsag.org a écrit :
On vendredi 3 décembre 2021 19:21:12 CET, Wallace wrote:
avec >&/dev/null tu ne rediriges pas stderr
Avec bash, csh, ou zsh, si : https://wiki.bash-hackers.org/syntax/redirection#redirecting_output_and_erro...
Mais avec dash qui est plus posix de base (le /bin/sh par défaut sous debian), c'est interprété comme "script & : >/dev/null"
exemple :
$ echo $SHELL /bin/zsh $ ls good bad &>/dev/null $ $ readlink /bin/sh dash $ /bin/sh $ ls good bad &>/dev/null $ ls: impossible d'accéder à 'good': Aucun fichier ou dossier de ce type ls: impossible d'accéder à 'bad': Aucun fichier ou dossier de ce type
[1] + Done(2) ls good bad $
Donc c'est bien possible que de temps en temps, le script ne passe pas en tache de fond avant la fin du cron et affiche quelque chose
Pour rediriger stderr tu devrais avoir 2>&1 > /dev/null
et ca c'est la syntaxe portable.
On vendredi 3 décembre 2021 19:07:15 CET, David Ponzone wrote:
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
Liste de diffusion du FRsAG http://www.frsag.org/
Attention en revanche, 2>&1 >/dev/null n'a pas l'effet escompté ! L'ordre de redirection importe : celle ci-dessus va d'abord brancher stderr sur là où pointe stdout (donc le terminal), *puis* rediriger stdout vers /dev/null (mais sans toucher à stderr !). La bonne solution est >/dev/null 2>&1
Cf https://github.com/koalaman/shellcheck/wiki/SC2069 et https://mywiki.wooledge.org/BashFAQ/055 (PS : Shellcheck c'est le feu)
Thomas
Le ven. 3 déc. 2021 à 19:55, David Ponzone david.ponzone@gmail.com a écrit :
Vincent,
Merci t’es le meilleur, j’ai oublié que crontab utilisait /bin/sh par défaut, comme moi j’utilise bash sur root (et je redéfinis généralement SHELL dans la crontab, mais pas celle-là…) Ce qui est évidemment déroutant, c’est pourquoi 0.2% du temps seulement j’ai un email, alors que le source C envoie tout le temps à stderr, mais tu dois avoir raison, il doit y avoir un truc pas tout à fait atomique/linéaire dans l’exécution.
Effectivement, je vais repasser sur la syntaxe POSIX, rappelée par Wallace, ça sera plus propre.
Je savais que ça irait vite!
Merci
Le 3 déc. 2021 à 19:38, Vincent Tondellier via FRsAG frsag@frsag.org
a écrit :
On vendredi 3 décembre 2021 19:21:12 CET, Wallace wrote:
avec >&/dev/null tu ne rediriges pas stderr
Avec bash, csh, ou zsh, si :
https://wiki.bash-hackers.org/syntax/redirection#redirecting_output_and_erro...
Mais avec dash qui est plus posix de base (le /bin/sh par défaut sous
debian), c'est interprété comme "script & : >/dev/null"
exemple :
$ echo $SHELL /bin/zsh $ ls good bad &>/dev/null $ $ readlink /bin/sh dash $ /bin/sh $ ls good bad &>/dev/null $ ls: impossible d'accéder à 'good': Aucun fichier ou dossier de ce type ls: impossible d'accéder à 'bad': Aucun fichier ou dossier de ce type
[1] + Done(2) ls good bad $
Donc c'est bien possible que de temps en temps, le script ne passe pas
en tache de fond avant la fin du cron et affiche quelque chose
Pour rediriger stderr tu devrais avoir 2>&1 > /dev/null
et ca c'est la syntaxe portable.
On vendredi 3 décembre 2021 19:07:15 CET, David Ponzone wrote:
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
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Yep Thomas, je viens de m’en apercevoir et faire un mail à ce sujet.
C’est pour quand le shell intelligent qui devine ce que tu veux faire ?
Le 3 déc. 2021 à 20:02, Thomas Gaudin t.goudine@gmail.com a écrit :
Attention en revanche, 2>&1 >/dev/null n'a pas l'effet escompté ! L'ordre de redirection importe : celle ci-dessus va d'abord brancher stderr sur là où pointe stdout (donc le terminal), *puis* rediriger stdout vers /dev/null (mais sans toucher à stderr !). La bonne solution est >/dev/null 2>&1
Cf https://github.com/koalaman/shellcheck/wiki/SC2069 https://github.com/koalaman/shellcheck/wiki/SC2069 et https://mywiki.wooledge.org/BashFAQ/055 https://mywiki.wooledge.org/BashFAQ/055 (PS : Shellcheck c'est le feu)
J’ai fait une type, dans ma crontab, c’est en fait &>/dev/null.
Ceci dit tu es sûr de ton coup ? D’après ce que je lis et ce que je fais, dans les shells modernes >&/dev/null et/ou &>/dev/null ont été introduits comme équivalents à 2>&1 >/dev/null.
D’ailleurs:
[19:31:31] noc@monitoring:~$ ls -l titi ls: impossible d'accéder à 'titi': Aucun fichier ou dossier de ce type [19:31:45] noc@monitoring:~$ echo $? 2 [19:31:52] noc@monitoring:~$ ls -l titi >&/dev/null [19:32:02] noc@monitoring:~$ ls -l titi &>/dev/null
Je reprends les 20 cents ou pas ? :)
Le 3 déc. 2021 à 19:21, Wallace wallace@morkitu.org a écrit :
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 http://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/ http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
J’aurai suggéré pareil sans tester.
Le ven. 3 déc. 2021 à 19:21, Wallace wallace@morkitu.org a écrit :
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 FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
Le 03/12/2021 à 19:21, Wallace a écrit :
avec >&/dev/null tu ne rediriges pas stderr
Pour rediriger stderr tu devrais avoir 2>&1 > /dev/null
En complément de la réponse de Wallace (extrait de [1]) :
com 2>&1 redirige la sortie des erreurs de com vers la sortie standard de com
Donc oui com 2>&1 > /dev/null redirige la sortie des erreurs (file descriptor numéro 2) de com vers la sortie standard de com (file descriptor numéro 1) qui est redirigée à son tour vers /dev/null
La documentation de GNU Bash concernant les redirections [2] te donne toute l'explication complète.
[1] : https://fr.wikibooks.org/wiki/Programmation_Bash/Flux_et_redirections#R%C3%A... [2] :https://www.gnu.org/software/bash/manual/html_node/Redirections.html
Bien cordialement,
C’est rigolo qu’en 2021, on se prenne encore la tête sur des trucs pareils.
J’ai modifié la crontab et j’ai vérifié en dash:
commande 2>&1 >/dev/null -> pas bon (je vois stderr)
commande >/dev/null 2>&1 -> ok (je vois plus rien)
Pareil en bash.
Le 3 déc. 2021 à 19:45, Maxime DERCHE maxime@mouet-mouet.net a écrit :
Bonsoir,
Le 03/12/2021 à 19:21, Wallace a écrit :
avec >&/dev/null tu ne rediriges pas stderr Pour rediriger stderr tu devrais avoir 2>&1 > /dev/null
En complément de la réponse de Wallace (extrait de [1]) :
com 2>&1 redirige la sortie des erreurs de com vers la sortie standard de com
Donc oui com 2>&1 > /dev/null redirige la sortie des erreurs (file descriptor numéro 2) de com vers la sortie standard de com (file descriptor numéro 1) qui est redirigée à son tour vers /dev/null
La documentation de GNU Bash concernant les redirections [2] te donne toute l'explication complète.
[1] : https://fr.wikibooks.org/wiki/Programmation_Bash/Flux_et_redirections#R%C3%A... [2] :https://www.gnu.org/software/bash/manual/html_node/Redirections.html
Bien cordialement,
Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 https://www.mouet-mouet.net/maxime/blog/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Fri, Dec 03, 2021 at 08:03:04PM +0100, David Ponzone wrote:
C???est rigolo qu???en 2021, on se prenne encore la tête sur des trucs pareils.
J???ai modifié la crontab et j???ai vérifié en dash:
commande 2>&1 >/dev/null -> pas bon (je vois stderr)
commande >/dev/null 2>&1 -> ok (je vois plus rien)
en fait le "2>&1" signifie de rediriger stderr vers la ou pointe stdout.
Donc il faut d'abord faire pointer stdout vers null (> /dev/null) avant de dire a stderr d'aller vers la meme chose (2>&1).
a+,
On 3 Dec 2021, at 19:21, Wallace wallace@morkitu.org wrote:
avec >&/dev/null tu ne rediriges pas stderr
& fonctionne en csh et tcsh.
V.
On Fri, 3 Dec 2021 19:07:15 +0100 David Ponzone david.ponzone@gmail.com wrote:
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 :)
Je ne suis pas ce que vous dites, mais je pense après avoir déjà utilisé des lignes dans le genre lors de sessions de débug, qu'il pourrait y avoir un détail à améliorer, peut-être comme ceci en fonction du résultat recherché:
*************
https://memo-linux.com/cest-quoi-devnull-1
“*4*** /home/fred/script/test.sh >/dev/null 2>&1
Dans ce cas, l’administrateur ou root ne (saura) jamais si la commande c’est bien exécutées ou pas. Sauf, si le test est prévue dans le scripte test.sh.”
*************
Il y a probablement encore d'autres options. Je lirai ce que les membres de la liste proposent.
Cordialement, Joyce MARKOLL
-
contact＠orditux.org -
David Ponzone -
julien soula -
Maxime DERCHE -
Romain -
Thomas Gaudin -
Vincent Habchi -
Vincent Tondellier -
Wallace