Bonjour,
J'ai eu une nuit blanche à cause de cron:
Le petit script avec pgrep fournissait une malheureuse ligne en sortie (le
PID de eztream) standard si le processus existait.
Le souci c'est que si je ne redirigeait pas cette sortie, ou tout
simplement si je ne mettait pas un "&> /dev/null" (/dev/null ou tout
autre fichier) à la fin de l'entrée de la crontab, elle ne s'executait pas.
Autant j'étais au courant que si le verbiage de la commande à executer
était _trop_ important, cron le zappait, autant si ne savait pas que le
mutisme était de rigueur... enfin... maintenant je le sait...
--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath=91&products_id=456
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sébastien Kirche
Le 15 décembre 2005 à 10:12, R12y a dit :
Autant j'étais au courant que si le verbiage de la commande à executer était _trop_ important, cron le zappait, autant si ne savait pas que le mutisme était de rigueur... enfin... maintenant je le sait...
Si mes souvenirs sont bons, cela est redit de temps en temps sur fcolc et il me semble que le problème n'est pas de ne pas avoir de sortie, mais simplement de ne pas avoir de sortie sur la sortie standard.
Il suffit de rediriger dans un fichier si tu veux suivre ce qui se dit ou chez Dave comme tu l'as remarqué.
-- Sébastien Kirche
Le 15 décembre 2005 à 10:12, R12y a dit :
Autant j'étais au courant que si le verbiage de la commande à executer
était _trop_ important, cron le zappait, autant si ne savait pas que
le mutisme était de rigueur... enfin... maintenant je le sait...
Si mes souvenirs sont bons, cela est redit de temps en temps sur fcolc
et il me semble que le problème n'est pas de ne pas avoir de sortie,
mais simplement de ne pas avoir de sortie sur la sortie standard.
Il suffit de rediriger dans un fichier si tu veux suivre ce qui se dit
ou chez Dave comme tu l'as remarqué.
Autant j'étais au courant que si le verbiage de la commande à executer était _trop_ important, cron le zappait, autant si ne savait pas que le mutisme était de rigueur... enfin... maintenant je le sait...
Si mes souvenirs sont bons, cela est redit de temps en temps sur fcolc et il me semble que le problème n'est pas de ne pas avoir de sortie, mais simplement de ne pas avoir de sortie sur la sortie standard.
Il suffit de rediriger dans un fichier si tu veux suivre ce qui se dit ou chez Dave comme tu l'as remarqué.
-- Sébastien Kirche
Paul Gaborit
À (at) Thu, 15 Dec 2005 12:00:12 +0100, Sébastien Kirche écrivait (wrote):
Le 15 décembre 2005 à 10:12, R12y a dit :
Autant j'étais au courant que si le verbiage de la commande à executer était _trop_ important, cron le zappait, autant si ne savait pas que le mutisme était de rigueur... enfin... maintenant je le sait...
Si mes souvenirs sont bons, cela est redit de temps en temps sur fcolc et il me semble que le problème n'est pas de ne pas avoir de sortie, mais simplement de ne pas avoir de sortie sur la sortie standard.
Il suffit de rediriger dans un fichier si tu veux suivre ce qui se dit ou chez Dave comme tu l'as remarqué.
Ce comportement me semble complètement idiot. Avez-vous au moins un quelconque message d'erreur dans un quelconque fichier log ? Par ailleurs, la commande doit quand même être exécutée (sinon comment 'cron' saurait-il qu'elle produit une sortie quelconque ?).
Le cron de Solaris fait la chose suivante :
cron captures the output of the job's stdout and stderr streams, and, if it is non-empty, mails the output to the user. If the job does not produce output, no mail is sent to the user [...]
Et celui de FreeBSD et de NetBSD est encore plus pratique :
[...] cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in ``this'' crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named. MAILTO may also be used to direct mail to multiple recipients by seperating recipient users with a comma. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab.
Sur quel système avez-vous ce comportement ? Êtes-vous sûr de votre explication ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 15 Dec 2005 12:00:12 +0100,
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> écrivait (wrote):
Le 15 décembre 2005 à 10:12, R12y a dit :
Autant j'étais au courant que si le verbiage de la commande à executer
était _trop_ important, cron le zappait, autant si ne savait pas que
le mutisme était de rigueur... enfin... maintenant je le sait...
Si mes souvenirs sont bons, cela est redit de temps en temps sur fcolc
et il me semble que le problème n'est pas de ne pas avoir de sortie,
mais simplement de ne pas avoir de sortie sur la sortie standard.
Il suffit de rediriger dans un fichier si tu veux suivre ce qui se dit
ou chez Dave comme tu l'as remarqué.
Ce comportement me semble complètement idiot. Avez-vous au moins un
quelconque message d'erreur dans un quelconque fichier log ? Par
ailleurs, la commande doit quand même être exécutée (sinon comment
'cron' saurait-il qu'elle produit une sortie quelconque ?).
Le cron de Solaris fait la chose suivante :
cron captures the output of the job's stdout and stderr
streams, and, if it is non-empty, mails the output to the
user. If the job does not produce output, no mail is sent to
the user [...]
Et celui de FreeBSD et de NetBSD est encore plus pratique :
[...] cron(8) will look at MAILTO if it has any reason to send
mail as a result of running commands in ``this'' crontab. If
MAILTO is defined (and non-empty), mail is sent to the user so
named. MAILTO may also be used to direct mail to multiple
recipients by seperating recipient users with a comma. If MAILTO
is defined but empty (MAILTO=""), no mail will be sent.
Otherwise mail is sent to the owner of the crontab.
Sur quel système avez-vous ce comportement ? Êtes-vous sûr de votre
explication ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 15 Dec 2005 12:00:12 +0100, Sébastien Kirche écrivait (wrote):
Le 15 décembre 2005 à 10:12, R12y a dit :
Autant j'étais au courant que si le verbiage de la commande à executer était _trop_ important, cron le zappait, autant si ne savait pas que le mutisme était de rigueur... enfin... maintenant je le sait...
Si mes souvenirs sont bons, cela est redit de temps en temps sur fcolc et il me semble que le problème n'est pas de ne pas avoir de sortie, mais simplement de ne pas avoir de sortie sur la sortie standard.
Il suffit de rediriger dans un fichier si tu veux suivre ce qui se dit ou chez Dave comme tu l'as remarqué.
Ce comportement me semble complètement idiot. Avez-vous au moins un quelconque message d'erreur dans un quelconque fichier log ? Par ailleurs, la commande doit quand même être exécutée (sinon comment 'cron' saurait-il qu'elle produit une sortie quelconque ?).
Le cron de Solaris fait la chose suivante :
cron captures the output of the job's stdout and stderr streams, and, if it is non-empty, mails the output to the user. If the job does not produce output, no mail is sent to the user [...]
Et celui de FreeBSD et de NetBSD est encore plus pratique :
[...] cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in ``this'' crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named. MAILTO may also be used to direct mail to multiple recipients by seperating recipient users with a comma. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab.
Sur quel système avez-vous ce comportement ? Êtes-vous sûr de votre explication ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Sébastien Kirche
Le 15 décembre 2005 à 14:12, Paul Gaborit s'est exprimé ainsi :
Sur quel système avez-vous ce comportement ? Êtes-vous sûr de votre explication ?
C'est avec Linux.
Personnellement je connais cron mais je ne l'utilise pas, seulement c'est l'une des causes principales de problèmes avec cron d'après ce que je lis sur fcolc. Une autre étant de devoir parfois préciser le chemin complet d'une commande car le path peut être différent.
-- Sébastien Kirche
Le 15 décembre 2005 à 14:12, Paul Gaborit s'est exprimé ainsi :
Sur quel système avez-vous ce comportement ? Êtes-vous sûr de votre
explication ?
C'est avec Linux.
Personnellement je connais cron mais je ne l'utilise pas, seulement
c'est l'une des causes principales de problèmes avec cron d'après ce que
je lis sur fcolc. Une autre étant de devoir parfois préciser le chemin
complet d'une commande car le path peut être différent.
Le 15 décembre 2005 à 14:12, Paul Gaborit s'est exprimé ainsi :
Sur quel système avez-vous ce comportement ? Êtes-vous sûr de votre explication ?
C'est avec Linux.
Personnellement je connais cron mais je ne l'utilise pas, seulement c'est l'une des causes principales de problèmes avec cron d'après ce que je lis sur fcolc. Une autre étant de devoir parfois préciser le chemin complet d'une commande car le path peut être différent.
-- Sébastien Kirche
Nicolas George
Sébastien Kirche wrote in message :
Personnellement je connais cron mais je ne l'utilise pas, seulement c'est l'une des causes principales de problèmes avec cron d'après ce que je lis sur fcolc.
J'ai surtout l'impression que le problème vient d'un MTA pas configuré.
Sébastien Kirche
wrote in message <m2d5jye7jy.fsf@seki.fr>:
Personnellement je connais cron mais je ne l'utilise pas, seulement
c'est l'une des causes principales de problèmes avec cron d'après ce que
je lis sur fcolc.
J'ai surtout l'impression que le problème vient d'un MTA pas configuré.
Personnellement je connais cron mais je ne l'utilise pas, seulement c'est l'une des causes principales de problèmes avec cron d'après ce que je lis sur fcolc.
J'ai surtout l'impression que le problème vient d'un MTA pas configuré.
Sébastien Kirche
Le 15 décembre 2005 à 16:12, Nicolas George a dit :
Sébastien Kirche wrote in message :
Personnellement je connais cron mais je ne l'utilise pas, seulement c'est l'une des causes principales de problèmes avec cron d'après ce que je lis sur fcolc.
J'ai surtout l'impression que le problème vient d'un MTA pas configuré.
À la lecture de cron(8) j'ai l'impression que tu as raison et cette histoire de redirection de la sortie est encore un mythe de plus.
Je tâcherai de ne plus colporter cette rumeur.
-- Sébastien Kirche
Le 15 décembre 2005 à 16:12, Nicolas George a dit :
Sébastien Kirche
wrote in message <m2d5jye7jy.fsf@seki.fr>:
Personnellement je connais cron mais je ne l'utilise pas, seulement
c'est l'une des causes principales de problèmes avec cron d'après ce
que je lis sur fcolc.
J'ai surtout l'impression que le problème vient d'un MTA pas
configuré.
À la lecture de cron(8) j'ai l'impression que tu as raison et cette
histoire de redirection de la sortie est encore un mythe de plus.
Le 15 décembre 2005 à 16:12, Nicolas George a dit :
Sébastien Kirche wrote in message :
Personnellement je connais cron mais je ne l'utilise pas, seulement c'est l'une des causes principales de problèmes avec cron d'après ce que je lis sur fcolc.
J'ai surtout l'impression que le problème vient d'un MTA pas configuré.
À la lecture de cron(8) j'ai l'impression que tu as raison et cette histoire de redirection de la sortie est encore un mythe de plus.
Je tâcherai de ne plus colporter cette rumeur.
-- Sébastien Kirche
Bob qui Trolle
R12y wrote:
Bonjour, J'ai eu une nuit blanche à cause de cron: Le petit script avec pgrep fournissait une malheureuse ligne en sortie (le PID de eztream) standard si le processus existait. Le souci c'est que si je ne redirigeait pas cette sortie, ou tout simplement si je ne mettait pas un "&> /dev/null" (/dev/null ou tout autre fichier) à la fin de l'entrée de la crontab, elle ne s'execut ait pas. Autant j'étais au courant que si le verbiage de la commande à execu ter était _trop_ important, cron le zappait, autant si ne savait pas que le mutisme était de rigueur... enfin... maintenant je le sait...
Sous Unix, le système n'est pas un magicien, ni un régulateur : il fa ut de son mieux pour que ce que les programmes demandent soit fait.
Le système alloue au processus qu'il créé les canaux qu'il demande, laissant au processus parent (qui est à l'origine de la demande de création de ce nouveaux processus, qui commence normalement par être un clone de lui-même, la suite étant à nouveau l'affaire du code du processus parent cloné) la responsabilité de savoir quoi faire de ce que le processus enfant créé a demandé.
Lorsqu'un processus A demande la création d'un processus B et que B, pris d'une farouche indépendance (c'est son droit le plus strict de processus de suivre librement le code qui le guide), souhaite disposer de canaux d'entrée, de sortie, d'erreurs, etc., c'est au processus A de savir quoi faire des demandes de B (quoi mettre à 'lautre bout du tuyau ).
En mode interactif (sous shell), le shell s'occupe de cette bureaucratie et raccorde les canaux demandés par les processus créés par l'utilisateurs au terminal attribué à l'utilisateur lors que la cré ation du processus shell.
En mode non-interactif, c'est au programme par lequel est créé le processus parent de se démerder avec les demandes, notamment de canaux de sortie, des processus enfants.
Solution simple dans le cas d'une implé arbitraire de cron : écrire u ne redirection explicite et valide de l'ensemble des flux créés. Une redirection d'un flux de sortei dans /dev/null est toujours valide. Certaines implés ont quelques propositions à ce sujet (envoi de mail, etc.)
R12y wrote:
Bonjour,
J'ai eu une nuit blanche à cause de cron:
Le petit script avec pgrep fournissait une malheureuse ligne en sortie (le
PID de eztream) standard si le processus existait.
Le souci c'est que si je ne redirigeait pas cette sortie, ou tout
simplement si je ne mettait pas un "&> /dev/null" (/dev/null ou tout
autre fichier) à la fin de l'entrée de la crontab, elle ne s'execut ait pas.
Autant j'étais au courant que si le verbiage de la commande à execu ter
était _trop_ important, cron le zappait, autant si ne savait pas que le
mutisme était de rigueur... enfin... maintenant je le sait...
Sous Unix, le système n'est pas un magicien, ni un régulateur : il fa ut
de son mieux pour que ce que les programmes demandent soit fait.
Le système alloue au processus qu'il créé les canaux qu'il demande,
laissant au processus parent (qui est à l'origine de la demande de
création de ce nouveaux processus, qui commence normalement par être un
clone de lui-même, la suite étant à nouveau l'affaire du code du
processus parent cloné) la responsabilité de savoir quoi faire de ce que
le processus enfant créé a demandé.
Lorsqu'un processus A demande la création d'un processus B et que B,
pris d'une farouche indépendance (c'est son droit le plus strict de
processus de suivre librement le code qui le guide), souhaite disposer
de canaux d'entrée, de sortie, d'erreurs, etc., c'est au processus A de
savir quoi faire des demandes de B (quoi mettre à 'lautre bout du tuyau ).
En mode interactif (sous shell), le shell s'occupe de cette bureaucratie
et raccorde les canaux demandés par les processus créés par
l'utilisateurs au terminal attribué à l'utilisateur lors que la cré ation
du processus shell.
En mode non-interactif, c'est au programme par lequel est créé le
processus parent de se démerder avec les demandes, notamment de canaux
de sortie, des processus enfants.
Solution simple dans le cas d'une implé arbitraire de cron : écrire u ne
redirection explicite et valide de l'ensemble des flux créés. Une
redirection d'un flux de sortei dans /dev/null est toujours valide.
Certaines implés ont quelques propositions à ce sujet (envoi de mail, etc.)
Bonjour, J'ai eu une nuit blanche à cause de cron: Le petit script avec pgrep fournissait une malheureuse ligne en sortie (le PID de eztream) standard si le processus existait. Le souci c'est que si je ne redirigeait pas cette sortie, ou tout simplement si je ne mettait pas un "&> /dev/null" (/dev/null ou tout autre fichier) à la fin de l'entrée de la crontab, elle ne s'execut ait pas. Autant j'étais au courant que si le verbiage de la commande à execu ter était _trop_ important, cron le zappait, autant si ne savait pas que le mutisme était de rigueur... enfin... maintenant je le sait...
Sous Unix, le système n'est pas un magicien, ni un régulateur : il fa ut de son mieux pour que ce que les programmes demandent soit fait.
Le système alloue au processus qu'il créé les canaux qu'il demande, laissant au processus parent (qui est à l'origine de la demande de création de ce nouveaux processus, qui commence normalement par être un clone de lui-même, la suite étant à nouveau l'affaire du code du processus parent cloné) la responsabilité de savoir quoi faire de ce que le processus enfant créé a demandé.
Lorsqu'un processus A demande la création d'un processus B et que B, pris d'une farouche indépendance (c'est son droit le plus strict de processus de suivre librement le code qui le guide), souhaite disposer de canaux d'entrée, de sortie, d'erreurs, etc., c'est au processus A de savir quoi faire des demandes de B (quoi mettre à 'lautre bout du tuyau ).
En mode interactif (sous shell), le shell s'occupe de cette bureaucratie et raccorde les canaux demandés par les processus créés par l'utilisateurs au terminal attribué à l'utilisateur lors que la cré ation du processus shell.
En mode non-interactif, c'est au programme par lequel est créé le processus parent de se démerder avec les demandes, notamment de canaux de sortie, des processus enfants.
Solution simple dans le cas d'une implé arbitraire de cron : écrire u ne redirection explicite et valide de l'ensemble des flux créés. Une redirection d'un flux de sortei dans /dev/null est toujours valide. Certaines implés ont quelques propositions à ce sujet (envoi de mail, etc.)
Nicolas George
Bob qui Trolle wrote in message <43a26650$0$27907$:
et que B, pris d'une farouche indépendance (c'est son droit le plus strict de processus de suivre librement le code qui le guide), souhaite disposer de canaux d'entrée, de sortie, d'erreurs, etc., c'est au processus A de savir quoi faire des demandes de B (quoi mettre à 'lautre bout du tuyau).
Absolument pas. Ce n'est pas du tout come ça qu'Unix fonctionne : tu ferais mieux de réviser tes bases.
Bob qui Trolle wrote in message
<43a26650$0$27907$636a55ce@news.free.fr>:
et que B,
pris d'une farouche indépendance (c'est son droit le plus strict de
processus de suivre librement le code qui le guide), souhaite disposer
de canaux d'entrée, de sortie, d'erreurs, etc., c'est au processus A de
savir quoi faire des demandes de B (quoi mettre à 'lautre bout du tuyau).
Absolument pas. Ce n'est pas du tout come ça qu'Unix fonctionne : tu ferais
mieux de réviser tes bases.
Bob qui Trolle wrote in message <43a26650$0$27907$:
et que B, pris d'une farouche indépendance (c'est son droit le plus strict de processus de suivre librement le code qui le guide), souhaite disposer de canaux d'entrée, de sortie, d'erreurs, etc., c'est au processus A de savir quoi faire des demandes de B (quoi mettre à 'lautre bout du tuyau).
Absolument pas. Ce n'est pas du tout come ça qu'Unix fonctionne : tu ferais mieux de réviser tes bases.
