Quizz du vendredi soir: >&/dev/null
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, -- 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/>
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+, -- Julien << Vous n'avez rien a dire... Parlons-en! >>
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 -- Orditux Informatique https://orditux.org https://orditux.org/aol
participants (9)
-
contact＠orditux.org -
David Ponzone -
julien soula -
Maxime DERCHE -
Romain -
Thomas Gaudin -
Vincent Habchi -
Vincent Tondellier -
Wallace