La tâche Cron ne se déclenche pas après un changement de fuseau horaire

13

J'ai essayé d'éliminer bon nombre des erreurs courantes,

  1. s'assurer que les CHEMINS sont disponibles pour cron

  2. il y a une fin à la fin du fichier crontab

  3. le fuseau horaire est défini par:

    cd /etc
cp /usr/share/zoneinfo/Asia/Singapore /etc/localtime

En cours d'exécution dateen bash, je reçois:

Tue Sep 17 15:14:30 SGT 2013

Afin de vérifier si cron utilise en même temps,

* * * * * date >> date.txt

donne la même sortie de date dans date.txt.

Voici le script que j'essaie d'exécuter:

event.sh:

#!/usr/bin/env bash
echo data > /root/data.txt

En utilisant crontab -e, la ligne ci-dessous fonctionne,

* * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

15 * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

Cependant, lorsque j'ai essayé d'autres arguments, en espérant qu'il fonctionnerait à 14 h 50:

50 14 * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

ou

50 14 * * * (cd /root ; ./event.sh >/tmp/debug.log 2>&1)

cela ne fonctionnera plus. On dirait qu'il y a un problème avec mon argument d'heure. Rien n'a pu non plus être trouvé dans le /tmp/debug.logfichier.

SOLUTION:

Il s'est avéré que je dois redémarrer le service cron après avoir apporté des modifications à TZ.

cron timezone adsisco
la source
1
une erreur dans les journaux? pouvez-vous s'il vous plaît essayer avec un chemin absolu au lieu d' ~/event.shessayer avec/home/username/event.sh
Rahul Patil
1
faire aussi de petites modifications comme* * * * * /bin/bash /root/event.sh >/tmp/debuge.log 2>&1
Rahul Patil
1
Vous dites que le fuseau horaire est correctement réglé, mais en êtes-vous absolument sûr ? Essayez d'ajouter une entrée telle que * * * * * dateet confirmez qu'elle dateindique l'heure prévue. Notez que la définition de la variable d'environnement TZ à l' intérieur du crontab pourrait ne pas affecter le fuseau horaire tel qu'il est utilisé par le cron démon lui - même, mais il aura une incidence sur les processus lancés par cron, donc si vous définissez TZ dans votre crontab je vous suggère de le commenter sur temporairement et en définissant l'heure à l'aide du fuseau horaire de l'horloge système (probablement UTC si vous démarrez Linux, mais peut être l'heure locale) à la place.
un CVn du
1
Vous manquez le point, @adsisco. Je vous demande de supprimer toute directive TZ qui pourrait se trouver dans la crontab, puis de réessayer. Cela fera que la date s'exécutera avec le même TZ que le démon cron lui-même, nous permettant de voir dans quel fuseau horaire cron veut que les champs horaires se trouvent. / Etc / localtime affecte uniquement l'affichage, pas l'horloge système, et je doute que cela affecte cron. En faisant ce test, nous pouvons être sûrs que votre problème n'est en aucun cas lié aux fuseaux horaires (ce qui me semble franchement).
un CVn du
1
en fait, je pense que je viens de le corriger en redémarrant le système ... est-ce que je devrais redémarrer le service cron après avoir apporté des modifications à TZ? @ MichaelKjörling. MERCI! pour m'avoir signalé d'éventuels problèmes de fuseau horaire.
adsisco

Réponses:

7

Tout d'abord, les probabilités que vous rencontriez un bogue qui entraîne une prise en compte incorrecte d'un champ semblent exceptionnellement faibles. Il est plus probable qu'il s'agisse d'une incompréhension de ce qui se passe et de ce que cron attend.

Dans ce cas, nous avons découvert dans les commentaires à la question qu'il s'agissait très probablement d'un problème lié au fuseau horaire. Pour cela, vous devez:

  • Ajouter une entrée similaire * * * * * dateà la crontab
  • Supprimer (ou commenter) toute affectation TZ de la crontab

Cela force dateà s'exécuter avec le paramètre de fuseau horaire de l'invocateur, ce qui signifie le démon cron . Regardez la sortie; il montrera quel fuseau horaire cron utilise en interne, et donc très probablement dans quel fuseau horaire il veut que ses champs horaires se trouvent. Si vous avez une affectation TZ dans la crontab, il est facilement possible que l'affectation des variables d'environnement TZ soit transmise commandes invoquées mais cron lui-même utilise un autre fuseau horaire . En mettant en commentaire ou en supprimant l'affectation TZ, vous évitez cette ambiguïté.

Notez également que toute modification des paramètres du fuseau horaire global du système (y compris par exemple / etc / localtime) nécessite presque certainement au moins un redémarrage du démon cron, et éventuellement (bien que peu probable) un redémarrage du système pour prendre pleinement effet. La modification de l'affectation TZ dans la crontab ne devrait pas nécessiter un rechargement du démon cron, car elle devrait détecter que le fichier a été modifié et le recharger automatiquement.

un CVn
la source