Différence entre le crontab de root et /etc/cron ?
11 réponses
mpg
Bonjour,
Je suis pas bien sûr de savoir si ma question est commune à tous les Unix,
ou spécifique à Linux, peut-être même est-ce une pure Debiannerie. Bref,
pluriplublication fcolc et fcou, suivi fcolc au hasard.
Bon, alors j'aimerais bien automatiser certaines tâches sur ma machine qui
ont besoin d'être répétées à intervalle réguliers. Ces tâches sont à
effectuer en root. J'ai lu[1] man crontab(1) puis essayé de modifier la
crontab de root. Je me suis alors aperçu qu'elle était vide.
Ça m'a un rien surpris, vu qu'il y a quand même forcément des tâches
chroniques exécutées en root. Bref, je suis allé voir dans /etc/ et il y a
effectivement des sous-répertoires cron.daily à cron.monthly qui
contiennent des scripts.
Du coup, ma question est la suivante : quelle est la différence entre placer
un appel à script dans la crontab de root, et placer ledit script dans,
mettons, /etc/cron.weekly ?
Merci d'avance pour vos avis,
Manuel.
[1] par contre j'ai cherché en vain la page qui décrit la syntaxe du fichier
de crontab : j'ai fini par essayer au hasard à partir d'exemples vus ça et
là, ça a l'air de marcher, mais bon...
Du coup, ma question est la suivante : quelle est la différence entre placer un appel à script dans la crontab de root, et placer ledit script dans, mettons, /etc/cron.weekly ?
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécution, par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (même pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile pour les packages, il suffit à chaque package d'aller pondre un fichier au bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab de root.
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumée à l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénient. Sous Debian, si on installe anacron, c'est ce dernier qui exécute les /etc/cron.* à la place de cron.
[1] par contre j'ai cherché en vain la page qui décrit la syntaxe du fichier de crontab
Il y a une page « crontab » dans la section 5 qui décrit le format des crontabs. Si tu fais « man crontab » tout court, tu obtiens la page de la section 1 qui décrit le programme nommé « crontab » et non le format...
Pour info, tu pouvais trouver en regardant le see also de crontab(1), il y a « crontab(5) » dedans, et la section 5 est traditionellement consacrée aux formats de fichiers.
mpg :
Du coup, ma question est la suivante : quelle est la différence entre placer
un appel à script dans la crontab de root, et placer ledit script dans,
mettons, /etc/cron.weekly ?
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécution, par
exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (même pas
besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile
pour les packages, il suffit à chaque package d'aller pondre un fichier au
bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc/cron.*
sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab
de root.
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumée à
l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas
exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénient. Sous
Debian, si on installe anacron, c'est ce dernier qui exécute les /etc/cron.*
à la place de cron.
[1] par contre j'ai cherché en vain la page qui décrit la syntaxe du fichier
de crontab
Il y a une page « crontab » dans la section 5 qui décrit le format des
crontabs. Si tu fais « man crontab » tout court, tu obtiens la page de la
section 1 qui décrit le programme nommé « crontab » et non le format...
Pour info, tu pouvais trouver en regardant le see also de crontab(1), il y a
« crontab(5) » dedans, et la section 5 est traditionellement consacrée aux
formats de fichiers.
Du coup, ma question est la suivante : quelle est la différence entre placer un appel à script dans la crontab de root, et placer ledit script dans, mettons, /etc/cron.weekly ?
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécution, par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (même pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile pour les packages, il suffit à chaque package d'aller pondre un fichier au bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab de root.
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumée à l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénient. Sous Debian, si on installe anacron, c'est ce dernier qui exécute les /etc/cron.* à la place de cron.
[1] par contre j'ai cherché en vain la page qui décrit la syntaxe du fichier de crontab
Il y a une page « crontab » dans la section 5 qui décrit le format des crontabs. Si tu fais « man crontab » tout court, tu obtiens la page de la section 1 qui décrit le programme nommé « crontab » et non le format...
Pour info, tu pouvais trouver en regardant le see also de crontab(1), il y a « crontab(5) » dedans, et la section 5 est traditionellement consacrée aux formats de fichiers.
GuiGui
mpg :
Du coup, ma question est la suivante : quelle est la différence entr e placer un appel à script dans la crontab de root, et placer ledit script da ns, mettons, /etc/cron.weekly ?
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécut ion, par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (mê me pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile pour les packages, il suffit à chaque package d'aller pondre un fichi er au bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc /cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxièm e crontab de root.
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumé e à l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénien t. Sous Debian, si on installe anacron, c'est ce dernier qui exécute les /etc /cron.* à la place de cron.
Autre piège : la crontab de root est exécutée dans l'environnement de root, /etc/crontab /etc/cron.* et /etc/cron.d/* sont simplement exécuté s avec les droits root, sans garantie sur l'environnement (en fonction du système, ça peut ou pas être celui de root) donc pas de garantie po ur que le path soit le bon par exemple.
mpg :
Du coup, ma question est la suivante : quelle est la différence entr e placer
un appel à script dans la crontab de root, et placer ledit script da ns,
mettons, /etc/cron.weekly ?
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécut ion, par
exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (mê me pas
besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile
pour les packages, il suffit à chaque package d'aller pondre un fichi er au
bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc /cron.*
sont appellés via /etc/crontab, qui est en quelque sort une deuxièm e crontab
de root.
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumé e à
l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas
exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénien t. Sous
Debian, si on installe anacron, c'est ce dernier qui exécute les /etc /cron.*
à la place de cron.
Autre piège : la crontab de root est exécutée dans l'environnement de
root, /etc/crontab /etc/cron.* et /etc/cron.d/* sont simplement exécuté s
avec les droits root, sans garantie sur l'environnement (en fonction du
système, ça peut ou pas être celui de root) donc pas de garantie po ur
que le path soit le bon par exemple.
Du coup, ma question est la suivante : quelle est la différence entr e placer un appel à script dans la crontab de root, et placer ledit script da ns, mettons, /etc/cron.weekly ?
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécut ion, par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (mê me pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile pour les packages, il suffit à chaque package d'aller pondre un fichi er au bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc /cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxièm e crontab de root.
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumé e à l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénien t. Sous Debian, si on installe anacron, c'est ce dernier qui exécute les /etc /cron.* à la place de cron.
Autre piège : la crontab de root est exécutée dans l'environnement de root, /etc/crontab /etc/cron.* et /etc/cron.d/* sont simplement exécuté s avec les droits root, sans garantie sur l'environnement (en fonction du système, ça peut ou pas être celui de root) donc pas de garantie po ur que le path soit le bon par exemple.
mpg
Le (on) vendredi 23 novembre 2007 13:04, Luc Habert a écrit (wrote) :
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécution, par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (même pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile pour les packages, il suffit à chaque package d'aller pondre un fichier au bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab de root.
Oki. Du coup ça complique encore un tout petit peu mon choix : si je veux,
par exemple, que chaque jour ma machine vérifie si des mises à jour de sécurité son disponibles (machine sous Debian stable) et m'envoie un mail le cas échéant, je mets ça plutôt dans le vair crontab de root, dans /etc/crontab, ou dans /etc/cron.daily (sachant que je me fous de savoir à quelle heure c'est exécuté) ?
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumée à l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénient. Sous Debian, si on installe anacron, c'est ce dernier qui exécute les /etc/cron.* à la place de cron.
Merci pour ce détail intéressant. Il me semble qu'anacron est installé sur
mes deux machines (sous Debian), donc pas de problème pour le moment. Mais c'est bon à savoir en général.
Il y a une page « crontab » dans la section 5 qui décrit le format des crontabs. Si tu fais « man crontab » tout court, tu obtiens la page de la section 1 qui décrit le programme nommé « crontab » et non le format...
En effet.
Pour info, tu pouvais trouver en regardant le see also de crontab(1), il y a « crontab(5) » dedans, et la section 5 est traditionellement consacrée aux formats de fichiers.
Arf, j'avais effectivement vu ça, mais je ne savais plus que 5 était pour les format des fichiers : j'avais cru que c'était un truc pour les programmeurs.
Manuel.
Le (on) vendredi 23 novembre 2007 13:04, Luc Habert a écrit (wrote) :
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécution,
par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script
(même pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est
très utile pour les packages, il suffit à chaque package d'aller pondre un
fichier au bon endroit, au lieu de devoir éditer une crontab). En fait,
les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort
une deuxième crontab de root.
Oki. Du coup ça complique encore un tout petit peu mon choix : si je veux,
par exemple, que chaque jour ma machine vérifie si des mises à jour de
sécurité son disponibles (machine sous Debian stable) et m'envoie un mail
le cas échéant, je mets ça plutôt dans le vair crontab de root,
dans /etc/crontab, ou dans /etc/cron.daily (sachant que je me fous de
savoir à quelle heure c'est exécuté) ?
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumée à
l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas
exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénient. Sous
Debian, si on installe anacron, c'est ce dernier qui exécute les
/etc/cron.* à la place de cron.
Merci pour ce détail intéressant. Il me semble qu'anacron est installé sur
mes deux machines (sous Debian), donc pas de problème pour le moment. Mais
c'est bon à savoir en général.
Il y a une page « crontab » dans la section 5 qui décrit le format des
crontabs. Si tu fais « man crontab » tout court, tu obtiens la page de la
section 1 qui décrit le programme nommé « crontab » et non le format...
En effet.
Pour info, tu pouvais trouver en regardant le see also de crontab(1), il y
a « crontab(5) » dedans, et la section 5 est traditionellement consacrée
aux formats de fichiers.
Arf, j'avais effectivement vu ça, mais je ne savais plus que 5 était pour
les format des fichiers : j'avais cru que c'était un truc pour les
programmeurs.
Le (on) vendredi 23 novembre 2007 13:04, Luc Habert a écrit (wrote) :
Dans la crontab de root, tu as un contrôle plus fin (heure d'exécution, par exemple). Dans /etc/cron.*, il est plus facile d'ajouter un script (même pas besoin d'apprendre la syntaxe des crontabs; d'autre part, c'est très utile pour les packages, il suffit à chaque package d'aller pondre un fichier au bon endroit, au lieu de devoir éditer une crontab). En fait, les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab de root.
Oki. Du coup ça complique encore un tout petit peu mon choix : si je veux,
par exemple, que chaque jour ma machine vérifie si des mises à jour de sécurité son disponibles (machine sous Debian stable) et m'envoie un mail le cas échéant, je mets ça plutôt dans le vair crontab de root, dans /etc/crontab, ou dans /etc/cron.daily (sachant que je me fous de savoir à quelle heure c'est exécuté) ?
Il y a un piège avec ces /etc/cron.* : si la machine n'est pas allumée à l'heure prévue dans /etc/crontab, ça tombe à l'eau, le script ne sera pas exécuté au rallumage. Il y a anacron, qui n'a pas cet inconvénient. Sous Debian, si on installe anacron, c'est ce dernier qui exécute les /etc/cron.* à la place de cron.
Merci pour ce détail intéressant. Il me semble qu'anacron est installé sur
mes deux machines (sous Debian), donc pas de problème pour le moment. Mais c'est bon à savoir en général.
Il y a une page « crontab » dans la section 5 qui décrit le format des crontabs. Si tu fais « man crontab » tout court, tu obtiens la page de la section 1 qui décrit le programme nommé « crontab » et non le format...
En effet.
Pour info, tu pouvais trouver en regardant le see also de crontab(1), il y a « crontab(5) » dedans, et la section 5 est traditionellement consacrée aux formats de fichiers.
Arf, j'avais effectivement vu ça, mais je ne savais plus que 5 était pour les format des fichiers : j'avais cru que c'était un truc pour les programmeurs.
Manuel.
Pascal Hambourg
Salut,
En fait, les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab de root.
Ne serait-il pas plus exact de dire que c'est la crontab système ?
Salut,
En fait, les /etc/cron.*
sont appellés via /etc/crontab, qui est en quelque sort une deuxième crontab
de root.
Ne serait-il pas plus exact de dire que c'est la crontab système ?
En fait, les /etc/cron.* sont appellés via /etc/crontab, qui est en quelque sort une deuxiè me crontab de root.
Ne serait-il pas plus exact de dire que c'est la crontab système ?
Oui, d'où le problème d'environnement.
Luc.Habert.00__arjf
GuiGui :
Autre piège : la crontab de root est exécutée dans l'environnement de root
Euh, qu'entends-tu par là? Je viens de vérifier sur ma debian, le .profile d'un utilisateur n'est pas chargé pour exécuter les commandes de sa crontab.
GuiGui :
Autre piège : la crontab de root est exécutée dans l'environnement de
root
Euh, qu'entends-tu par là? Je viens de vérifier sur ma debian, le .profile
d'un utilisateur n'est pas chargé pour exécuter les commandes de sa crontab.
Autre piège : la crontab de root est exécutée dans l'environnement de root
Euh, qu'entends-tu par là? Je viens de vérifier sur ma debian, le .profile d'un utilisateur n'est pas chargé pour exécuter les commandes de sa crontab.
hého
Bonjour, bonjour,
[...] [1] par contre j'ai cherché en vain la page qui décrit la syntaxe du fichier de crontab :
man 5 crontab
cordialement hého
Bonjour,
bonjour,
[...]
[1] par contre j'ai cherché en vain la page qui décrit la syntaxe du fichier
de crontab :
oups, désolé pour le bruit, j'étais sur fcou, j'avais pas vu les
réponses ici, ni le fu2 qui a pourtant positionné mon champs destinataire. bon bah, bonne nuit...
GuiGui
GuiGui :
Autre piège : la crontab de root est exécutée dans l'environneme nt de root
Euh, qu'entends-tu par là? Je viens de vérifier sur ma debian, le . profile d'un utilisateur n'est pas chargé pour exécuter les commandes de sa crontab.
je te propose un test.
Tu fais un crontab -e sous root et tu mets :
* * * * * echo $PATH > /tmp/envroot
Tu edites /etc/crontab et tu ajoutes :
* * * * * root echo $PATH > /tmp/envsys
Tu attends 2 minutes et tu compares les fichiers. Sur mon Ubuntu, j'ai dans le premier cas : /usr/bin:/bin
et dans le deuxième cas /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
C'est pas vraiment la même chose.
GuiGui :
Autre piège : la crontab de root est exécutée dans l'environneme nt de
root
Euh, qu'entends-tu par là? Je viens de vérifier sur ma debian, le . profile
d'un utilisateur n'est pas chargé pour exécuter les commandes de sa crontab.
je te propose un test.
Tu fais un crontab -e sous root et tu mets :
* * * * * echo $PATH > /tmp/envroot
Tu edites /etc/crontab et tu ajoutes :
* * * * * root echo $PATH > /tmp/envsys
Tu attends 2 minutes et tu compares les fichiers. Sur mon Ubuntu, j'ai
dans le premier cas :
/usr/bin:/bin
et dans le deuxième cas
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Autre piège : la crontab de root est exécutée dans l'environneme nt de root
Euh, qu'entends-tu par là? Je viens de vérifier sur ma debian, le . profile d'un utilisateur n'est pas chargé pour exécuter les commandes de sa crontab.
je te propose un test.
Tu fais un crontab -e sous root et tu mets :
* * * * * echo $PATH > /tmp/envroot
Tu edites /etc/crontab et tu ajoutes :
* * * * * root echo $PATH > /tmp/envsys
Tu attends 2 minutes et tu compares les fichiers. Sur mon Ubuntu, j'ai dans le premier cas : /usr/bin:/bin
et dans le deuxième cas /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
