Solution 1 :
Il peut être utile de noter que les tâches dans une crontab personnelle (crontab -e ) sont toujours exécutés en tant que leur propriétaire, où /etc/crontab contient un <user> obligatoire supplémentaire permettant à un administrateur de configurer le travail pour qu'il s'exécute en tant qu'utilisateur non root.
La modification de la crontab système ou la configuration d'une crontab personnelle pour root sont probablement un peu plus portables, non spécifiques à certaines distributions Linux et sans doute plus pratiques pour une personne à maintenir, avec tous les jobs dans un seul fichier mais :
Personnellement, je privilégie une troisième option :pour chaque tâche planifiée déposez soit
- un fichier en
/etc/cron.d/avec un extrait cron - un exécutable (script) dans le
/etc/cron.[hourly |daily |weekly |monthly]correspondant répertoire.
C'est plus facile à scripter (vous pouvez simplement créer/écraser/supprimer de tels fichiers et vous n'avez pas à vous soucier du contenu d'un seul fichier crontab) et cela fonctionne bien avec les outils de gestion de configuration et c'est ce que les gestionnaires de paquets sont déjà faire quand même.
Travaux/scripts en /etc/cron.[hourly |daily |weekly |monthly] sont toujours exécutés en tant que root, où les extraits cron dans /etc/cron.d/ autoriser à la fois la définition d'un horaire personnalisé et l'exécution en tant qu'utilisateur différent avec le même <user> obligatoire champ trouvé dans /etc/crontab .
Solution 2 :
Au mieux de mes souvenirs, crontab -e a l'avantage supplémentaire de vérifier la syntaxe crontab avant de l'installer, et de générer une erreur et de restaurer la précédente si vous faites une erreur. De cette façon, tout ce qui fonctionnait auparavant ne s'arrêtera pas soudainement si vous vous trompez de syntaxe. Je pense que la meilleure pratique consiste à utiliser les utilitaires, comme exécuter visudo plutôt que de modifier /etc/sudoers directement.
Solution 3 :
C'est vraiment une question de style, il y a une raison pour laquelle plusieurs méthodes sont proposées par le système d'exploitation. Soyez simplement cohérent et ne mélangez pas si vous ne voulez pas confondre quelqu'un d'autre (ou vous-même après un certain temps sans avoir affaire au système) - s'il est difficile de voir quelles tâches sont réellement planifiées sur l'ensemble de l'hôte, cela a tendance pour finir en mauvaises surprises.
Solution 4 :
Afin d'être sûr d'ajouter une tâche cron qui nécessite les droits d'un utilisateur spécifique, j'utilise personnellement la commande suivante :
# crontab -u <user> -e
Vous pouvez ajouter sudo aussi.
Comme @rackandboneman l'a déclaré, il n'est pas nécessaire de jouer avec les fichiers /etc/cron.d/. Si le problème concerne les tâches cron de l'utilisateur, utilisez les fonctionnalités de crontab commande.