Différence entre le crontab de root et /etc/cron ?

Le
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Luc.Habert.00__arjf
Le #1906946
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.

GuiGui
Le #1906944
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
Le #1906943
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
Le #1906942
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 ?

Luc.Habert.00__arjf
Le #1906941
Si tu veux. Tout ça ne devrait pas nous faire perdre de vue le débat
important : faut-il mettre les répertoires personels dans /home ou dans
/users?
GuiGui
Le #1906940
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 ?


Oui, d'où le problème d'environnement.


Luc.Habert.00__arjf
Le #1906939
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.

hého
Le #1906938
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

hého
Le #1906937
Bonjour,
cordialement

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
Le #1906933
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.


Publicité
Poster une réponse
Anonyme