j'etais plutot content d'1&1 jusqu'=E0 aujourd'hui mais la franchement
.=2E.
il y a quelques jours , j'essaye leurs taches cron , je rentre tout en
ssh et pour tester je met l'execution toutes les minutes ( pendant
quelques minutes , un petit fichier de test ).
la tache ne fonctionne pas , forcemment , ils ont une configuration
totallement hallucinante et le cron daemon semble etre dans un endroit
inacessible ( en tout cas , pas trouv=E9 ) , je laisse donc tout comme
=E7a , en pensant qu'ils redemarrent le cron pour tout les clients
quotidiennement.
les jours passent , la tache ne fonctionne toujours pas , mais je
recois un mail du support qui me dit que mon compte va etre bloqu=E9 si
je ne r=E9gle pas le probleme dans la seconde.
pour leur faire plaisir , je modifie l'execution et je la met toutes
les heures , j'envoi une r=E9ponse au support en pr=E9cisant que la tache
ne fonctionne pas ( sous entendu si vous avez plus d'infos je suis
preneur ) et que donc =E7a n'avait aucune incidence ...
aujourd'hui je recois le meme mail ( votre compte va etre suspendu bla
bla bla ) , donc ils n'ont meme pas v=E9rifi=E9 que les changements
avaient =E9t=E9 effectu=E9 et pire ils ne connaissent visiblement pas leur
propre infrastructure et ne sont donc pas capable de me dire o=F9 se
trouve le cron daemon , ils ne sont pas non plus capable apparement de
faire la difference entre une tache qui s'execute et une tache qui ne
s'execute pas, bref =E7a fait peur ...
Tenez, moi je fais ça aussi avec ma voiture : je relance le moteur à chaque fois que je change la configuration de la boîte à vitesses, [...]
Mieux : j'ai un ami apprenti pilote qui le fait aussi avec son avion.
Y'a une boîte à vitesses sur son avion ?
Spyou
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix. J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu comprends, c'est un spécialiste, nous on n'y connaît rien...
Ce n'est pas parce que vous ne faites pas une chose , que c'est forcement mal , redemarrer le crond , ça ne coute rien et ça prends quoi ... 2 secondes ? ça permet d'etre sur que le crond tourne
man ps
, et en plus , les modifs de la crontab sont prises en compte instantanément
oui, et pis la cron qui devait partir a la premiere seconde en plein milieu du redemarrage de crond, elle part pas.
, quand on est méthodique et rigoureux , perdre deux secondes pour se concentrer uniquement sur un seul point , ça ne me parait pas du tout stupide
Quand on est methodique et rigoureux, on a des methodes. redemarrer crond ne sers *a rien*.
Un peu comme si, pour faire cycler les fichiers de logs apache, on disait "ben, y'a qu'a killer apache et le relancer .. baaahh .. ca prends que 2 secondes"
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix.
J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu
comprends, c'est un spécialiste, nous on n'y connaît rien...
Ce n'est pas parce que vous ne faites pas une chose , que c'est
forcement mal , redemarrer le crond , ça ne coute rien et ça prends
quoi ... 2 secondes ?
ça permet d'etre sur que le crond tourne
man ps
, et en plus , les modifs de
la crontab sont prises en compte instantanément
oui, et pis la cron qui devait partir a la premiere seconde en plein
milieu du redemarrage de crond, elle part pas.
, quand on est
méthodique et rigoureux , perdre deux secondes pour se concentrer
uniquement sur un seul point , ça ne me parait pas du tout stupide
Quand on est methodique et rigoureux, on a des methodes. redemarrer
crond ne sers *a rien*.
Un peu comme si, pour faire cycler les fichiers de logs apache, on
disait "ben, y'a qu'a killer apache et le relancer .. baaahh .. ca
prends que 2 secondes"
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix. J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu comprends, c'est un spécialiste, nous on n'y connaît rien...
Ce n'est pas parce que vous ne faites pas une chose , que c'est forcement mal , redemarrer le crond , ça ne coute rien et ça prends quoi ... 2 secondes ? ça permet d'etre sur que le crond tourne
man ps
, et en plus , les modifs de la crontab sont prises en compte instantanément
oui, et pis la cron qui devait partir a la premiere seconde en plein milieu du redemarrage de crond, elle part pas.
, quand on est méthodique et rigoureux , perdre deux secondes pour se concentrer uniquement sur un seul point , ça ne me parait pas du tout stupide
Quand on est methodique et rigoureux, on a des methodes. redemarrer crond ne sers *a rien*.
Un peu comme si, pour faire cycler les fichiers de logs apache, on disait "ben, y'a qu'a killer apache et le relancer .. baaahh .. ca prends que 2 secondes"
L'intérêt technique n'était peut-être pas là, mais l'intérê t était de te faire remarquer que tu as eu une réaction à mon goût qui est excess ive.
Si 1&1 te préviens d'un problème, c'est certainement pas pour t'embê ter, mais c'est pour une bonne raison à mon avis : garder un service de qualité sur du "mutualisé".
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 an s que j'édite des sites web , que j'ai eu à gerer des serveurs dédi és etc ...
Tu as peut-être de l'expérience, peut-être même plus que moi, mai s c'est pas pour autant que l'on sait tout. Comment est-ce qu'il disent dans le proverbe : "On a toujours besoin d'un plus petit que soit.".
... le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
... si quelqu'un trouve ça intuitif ...
C'est peut-être pas intuitif pour toi, mais facilement retrouvable comm e te l'on indiqué plusieurs personnes.
Pour apporter un intérêt technique, je reviens encore sur ton exécu tion toutes les minutes par tâche cron.
Je te conseille, d'écrire ta tâche de la manière suivante : */1 * * * * $HOME/monscript au lieu de : * * * * * $HOME/monscript
Tu va me dire que c'est la même chose, mais ce n'est pas tout à fait la même chose. En fait cela permet d'éviter que le script soit relancé , si la précédente exécution du script ne s'est pas encore terminée. J e pense que rien que cela t'aurais évité l'avertissement de 1&1.
Je vais t'expliquer pourquoi la deuxième écriture est dangereuse.
En fait, en général, les tâches cron sont exécutées avec une pr iorité bien plus faible que les autres processus, et donc même si en local ta commande te parait s'exécuter rapidement, elle peut prendre plus de 1 minutes sur le serveur mutualisé, et le fait de ré exécuter la comm ande toutes les minutes sans avoir vérifié que la précédente exécuti on se soit terminer, va entraîner le serveur dans un cercle vicieux : tâche lancée 1 fois -> augmentation charge processeur -> tâche lancée 2 f ois -> augmentation charge processeur -> tâche lancée 3 fois -> augmentat ion charge processeur -> tâche lancée 4 fois -> ...
Je t'avoue, je ne le savais pas non plus hier, mais par curiosité hier suite à ton message, je me suis un peu renseigné sur internet, et je suis tombé sur un article où j'ai lu cela. Malheureusement, je n'ai p as retrouvé l'article (si quelqu'un le retrouve merci de le mettre en lien), mais d'autres pourront le cas échéant me corriger ou me complé ter.
Amicalement. -- RURA Emma
Salut
bla bla bla , sans interet
L'intérêt technique n'était peut-être pas là, mais l'intérê t était de te
faire remarquer que tu as eu une réaction à mon goût qui est excess ive.
Si 1&1 te préviens d'un problème, c'est certainement pas pour t'embê ter,
mais c'est pour une bonne raison à mon avis : garder un service de
qualité sur du "mutualisé".
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 an s
que j'édite des sites web , que j'ai eu à gerer des serveurs dédi és
etc ...
Tu as peut-être de l'expérience, peut-être même plus que moi, mai s c'est
pas pour autant que l'on sait tout. Comment est-ce qu'il disent dans le
proverbe : "On a toujours besoin d'un plus petit que soit.".
... le chemin d'accé vers un fichier mis en ligne :
/kunden/homepages/yy/dxxxxxxxxx/htdocs/
... si quelqu'un trouve ça intuitif ...
C'est peut-être pas intuitif pour toi, mais facilement retrouvable comm e
te l'on indiqué plusieurs personnes.
Pour apporter un intérêt technique, je reviens encore sur ton exécu tion
toutes les minutes par tâche cron.
Je te conseille, d'écrire ta tâche de la manière suivante :
*/1 * * * * $HOME/monscript
au lieu de :
* * * * * $HOME/monscript
Tu va me dire que c'est la même chose, mais ce n'est pas tout à fait la
même chose. En fait cela permet d'éviter que le script soit relancé , si
la précédente exécution du script ne s'est pas encore terminée. J e pense
que rien que cela t'aurais évité l'avertissement de 1&1.
Je vais t'expliquer pourquoi la deuxième écriture est dangereuse.
En fait, en général, les tâches cron sont exécutées avec une pr iorité
bien plus faible que les autres processus, et donc même si en local ta
commande te parait s'exécuter rapidement, elle peut prendre plus de 1
minutes sur le serveur mutualisé, et le fait de ré exécuter la comm ande
toutes les minutes sans avoir vérifié que la précédente exécuti on se
soit terminer, va entraîner le serveur dans un cercle vicieux : tâche
lancée 1 fois -> augmentation charge processeur -> tâche lancée 2 f ois
-> augmentation charge processeur -> tâche lancée 3 fois -> augmentat ion
charge processeur -> tâche lancée 4 fois -> ...
Je t'avoue, je ne le savais pas non plus hier, mais par curiosité hier
suite à ton message, je me suis un peu renseigné sur internet, et je
suis tombé sur un article où j'ai lu cela. Malheureusement, je n'ai p as
retrouvé l'article (si quelqu'un le retrouve merci de le mettre en
lien), mais d'autres pourront le cas échéant me corriger ou me complé ter.
L'intérêt technique n'était peut-être pas là, mais l'intérê t était de te faire remarquer que tu as eu une réaction à mon goût qui est excess ive.
Si 1&1 te préviens d'un problème, c'est certainement pas pour t'embê ter, mais c'est pour une bonne raison à mon avis : garder un service de qualité sur du "mutualisé".
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 an s que j'édite des sites web , que j'ai eu à gerer des serveurs dédi és etc ...
Tu as peut-être de l'expérience, peut-être même plus que moi, mai s c'est pas pour autant que l'on sait tout. Comment est-ce qu'il disent dans le proverbe : "On a toujours besoin d'un plus petit que soit.".
... le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
... si quelqu'un trouve ça intuitif ...
C'est peut-être pas intuitif pour toi, mais facilement retrouvable comm e te l'on indiqué plusieurs personnes.
Pour apporter un intérêt technique, je reviens encore sur ton exécu tion toutes les minutes par tâche cron.
Je te conseille, d'écrire ta tâche de la manière suivante : */1 * * * * $HOME/monscript au lieu de : * * * * * $HOME/monscript
Tu va me dire que c'est la même chose, mais ce n'est pas tout à fait la même chose. En fait cela permet d'éviter que le script soit relancé , si la précédente exécution du script ne s'est pas encore terminée. J e pense que rien que cela t'aurais évité l'avertissement de 1&1.
Je vais t'expliquer pourquoi la deuxième écriture est dangereuse.
En fait, en général, les tâches cron sont exécutées avec une pr iorité bien plus faible que les autres processus, et donc même si en local ta commande te parait s'exécuter rapidement, elle peut prendre plus de 1 minutes sur le serveur mutualisé, et le fait de ré exécuter la comm ande toutes les minutes sans avoir vérifié que la précédente exécuti on se soit terminer, va entraîner le serveur dans un cercle vicieux : tâche lancée 1 fois -> augmentation charge processeur -> tâche lancée 2 f ois -> augmentation charge processeur -> tâche lancée 3 fois -> augmentat ion charge processeur -> tâche lancée 4 fois -> ...
Je t'avoue, je ne le savais pas non plus hier, mais par curiosité hier suite à ton message, je me suis un peu renseigné sur internet, et je suis tombé sur un article où j'ai lu cela. Malheureusement, je n'ai p as retrouvé l'article (si quelqu'un le retrouve merci de le mettre en lien), mais d'autres pourront le cas échéant me corriger ou me complé ter.
Amicalement. -- RURA Emma
Manuel Guesdon
On Wed, 28 Jun 2006 20:53:25 -0700, Xaero wrote:
Ce n'est pas parce que vous ne faites pas une chose , que c'est forcement mal , redemarrer le crond , ça ne coute rien et ça prends quoi ... 2 secondes ?
J'suis sans doute un peu bete mais pour reloader la crontab, je fais un crond reload Idem, pas besoin de faire un 'reboot' pour relancer un service ni d'une mitrailleuse pour ecraser un mouche :-)
Manuel
On Wed, 28 Jun 2006 20:53:25 -0700, Xaero wrote:
Ce n'est pas parce que vous ne faites pas une chose , que c'est
forcement mal , redemarrer le crond , ça ne coute rien et ça prends
quoi ... 2 secondes ?
J'suis sans doute un peu bete mais pour reloader la crontab, je fais un
crond reload
Idem, pas besoin de faire un 'reboot' pour relancer un service ni d'une
mitrailleuse pour ecraser un mouche :-)
Ce n'est pas parce que vous ne faites pas une chose , que c'est forcement mal , redemarrer le crond , ça ne coute rien et ça prends quoi ... 2 secondes ?
J'suis sans doute un peu bete mais pour reloader la crontab, je fais un crond reload Idem, pas besoin de faire un 'reboot' pour relancer un service ni d'une mitrailleuse pour ecraser un mouche :-)
Manuel
Mihamina Rakotomandimby
On Thu, 29 Jun 2006 07:28:54 +0000, Le GBAHB wrote:
Y'a une boîte à vitesses sur son avion ? Bien sûr. A la différence d'une voiture, le levier de vitesses est
placé entre les jambes du conducteur,
C'est pour ça que j'ai pas encore vu de femme pilotes d'avion... :-P
On Thu, 29 Jun 2006 07:28:54 +0000, Le GBAHB wrote:
Y'a une boîte à vitesses sur son avion ?
Bien sûr. A la différence d'une voiture, le levier de vitesses est
placé entre les jambes du conducteur,
C'est pour ça que j'ai pas encore vu de femme pilotes d'avion...
:-P
