bonjour,
j'ai installé un serveur avec Debian Squeeze, et j'ai remarqué que si on crée une tâche cron dans /etc/crontab ça fonctionne, si on crée une tâche en tant qu'utilisateur avec la commande "crontab -e" également, par contre cette dernière commande ne semble pas être prise en compte si on est root, pourtant il est possible de la lancer et d'éditer des tâches, qui ne seront pas exécutées. Est-ce qu'il y a une raison à cela ?
# Tu bluffes Martoni !
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 3.
C'est pas un problème avec la commande que tu lances plutôt ? par-ce que normalement ça marche.
# cron.deny ?
Posté par Jean-Yves LENHOF (site web personnel) . Évalué à 0.
Tu n'aurais pas un fichier /etc/cron.deny avec qq chose qui interdit que root ait une crontab ?
[^] # Re: cron.deny ?
Posté par fravashyo (site web personnel) . Évalué à 1.
non, rien de ça
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# Remarque importante + piste
Posté par ze_lionix (site web personnel) . Évalué à 2.
Salut,
A ta place j'éviterais de toucher au fichier /etc/crontab, je sais cela marche mais c'est plus ou moins un fichier de configuration, surtout pour anacron ! Les fichiers de crontab utilisateurs sont dans /var/spool/cron/[user] et chacun a le sien, root y compris. Si tu modifies les fichiers en direct il faut recharger cron, donc le mieux est de passer par crontab -e.
Pour ton soucis, sachant que sous squeeze la cron root marche très bien, sans configuration ou autre :
as tu bien laissé 2 minutes d'écart entre l'heure courante et l'heure de ton test de déclenchement ?
il se peux que ton script ne se fasse rien car il te manque des variables d'environnement ( la variables de cron sont très minimales ), as tu essayé de rediriger le résultat ?
ex : 06 14 * * * /root/mon_script > /tmp/out_monscript.log 2>&1
as tu regardé tes logs systèmes, normalement tu as une ligne du style "CRON[pid];pam_unis(cron:session) : session opened for user root "
Fuse : j'en Use et Abuse !
[^] # Re: Remarque importante + piste
Posté par fravashyo (site web personnel) . Évalué à 1.
bon, désolé pour le dérangement, ça refonctionne, sur le modèle du /etc/crontab j'avais (bêtement) rajouté le nom de l'utilisateur qui effectue la tâche, et ça fonctionnait pour l'utilisateur simple mais pas pour le root. Ou bien il s'agissait d'autre chose (saut de ligne ?)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Remarque importante + piste
Posté par Marotte ⛧ . Évalué à 3.
Quel est le rapport avec anacron ? /etc/crontab c'est la crontab système, une tâche ajoutée dans cette crontab sera prise en compte sans avoir besoin de redémarrer le service cron.
anacron n'est pas un daemon, il se lance, fait ce qu'il y a à faire et se termine. On peut donc le lancer via son .profile pour qu'il s'exécute lorsque l'on se connecte ou le lancer à intervalle régulier via cron. anacron utilise son propre fichier de configuration (avec les tâches à faire) et un répertoire dans lequel il va stocker des drapeaux pour savoir quand telle ou telle tâche a été exécutée. Je ne comprends donc pas ce qu'il vient faire ici.
[^] # Re: Remarque importante + piste
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 12 novembre 2012 à 19:09.
Pour préciser, sur Debian. Il est effectivement fait mention de anacron dans /etc/crontab avec 3 lignes telles que celle-ci :
(pareil pour weekly et monthly)
En fait ces lignes s'interprètent ainsi : Si /usr/sbin/anacron n'existe pas on exécute ce qui se trouve dans /etc/cron.daily
Ça vient simplement du fait que si anacron est installé c'est lui que Debian va charger de s'occuper des tâches quotidiennes, hebdomadaires et mensuelles.
[^] # Re: Remarque importante + piste
Posté par ze_lionix (site web personnel) . Évalué à 1.
Oui j'ai lu un peu vite le contenu du fichier /etc/crontab vis à vis d'anacron je te le concède.
Par contre il y a le déclenchement du cron.hourly qui passe par ce fichier, il ne faut pas le pourrir par erreur donc…
Moi _ ca n'engage que moi _ je trouve que gérer des cron utilsateurs sur /etc/crontab est "sale" car
1) ce fichier n'est pas modifiable par les users
2) quand tu édites ta crontab tu ne les vois pas, ce qui peut être générateur d'erreur
( ex : je le met en cron root alors qu'il est dans /etc/crontab, double lancement qui peux poser des soucis ).
Fuse : j'en Use et Abuse !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.