Zadanie Cron nie uruchamia się po zmianie strefy czasowej

Próbowałem wyeliminować wiele typowych błędów,

upewnienie się, że ŚCIEŻKI są dostępne dla crona
na końcu pliku crontab znajduje się linia końcowa

strefę czasową konfiguruje:

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

Uruchamiając datebash otrzymuję:

Tue Sep 17 15:14:30 SGT 2013

Aby sprawdzić, czy cron używa tego samego czasu,

* * * * * date >> date.txt

daje tę samą datę wyjściową w date.txt.

Oto skrypt, który próbuję wykonać:

event.sh:

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

Korzystając crontab -ez poniższej linii,

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

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

Jednak gdy wypróbowałem kilka innych argumentów, mam nadzieję, że zadziała o godzinie 2.50:

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

lub

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

przestanie działać. Wygląda na to, że jest problem z moją godzinną kłótnią. W /tmp/debug.logpliku nie można również znaleźć niczego .

ROZWIĄZANIE:

Okazało się, że muszę ponownie uruchomić usługę cron po dokonaniu zmian w TZ.

cron timezone

— adsisco
źródło

jakiś błąd w logach? czy możesz spróbować z absolutną ścieżką zamiast ~/event.shspróbować z/home/username/event.sh

— Rahul Patil

również dokonaj niewielkich modyfikacji, takich jak* * * * * /bin/bash /root/event.sh >/tmp/debuge.log 2>&1

— Rahul Patil

Mówisz, że strefa czasowa jest ustawiona poprawnie, ale czy jesteś tego absolutnie pewien ? Spróbuj dodać pozycję polub * * * * * datei potwierdź, że datepokazuje oczekiwany czas. Zauważ, że ustawienie zmiennej środowiskowej TZ z poziomu pliku crontab może nie wpływać na strefę czasową używaną przez samego demona cron, ale wpłynie na procesy uruchamiane przez cron, więc jeśli ustawisz TZ na swoim crontabie, sugeruję tymczasowe skomentowanie i ustawianie czasu za pomocą strefy czasowej zegara systemowego (prawdopodobnie UTC, jeśli uruchamiasz system Linux pojedynczo, ale może to być czas lokalny).

— CVn

Brakuje Ci punktu @adsisco. Proszę o usunięcie wszelkich dyrektyw TZ, które mogą znajdować się w pliku crontab, a następnie spróbuj ponownie. Spowoduje to, że data będzie wykonywana z tym samym TZ, co sam demon cron, co pozwoli nam zobaczyć, w jakiej strefie czasowej cron chce, aby pola czasowe miały wpływ. / Etc / localtime wpływa tylko na wyświetlanie, a nie na zegar systemowy, i wątpię, aby wpływał na cron. Wykonując ten test, możemy być pewni, że Twój problem nie jest w żaden sposób związany ze strefami czasowymi (które, szczerze mówiąc, wydaje mi się, że tak).

— CVn

właściwie myślę, że właśnie to naprawiłem poprzez ponowne uruchomienie systemu ... czy to możliwe, że muszę ponownie uruchomić usługę cron po wprowadzeniu zmian w TZ? @ MichaelKjörling. DZIĘKI! za wskazanie mi możliwych problemów ze strefą czasową.

— adsisco

Po pierwsze, szanse, że trafisz na błąd, który powoduje nieprawidłowe uwzględnienie jednego pola, wydają się wyjątkowo niskie. Bardziej prawdopodobne jest nieporozumienie, co się dzieje i czego oczekuje cron.

W tym przypadku w komentarzach do pytania stwierdziliśmy, że najprawdopodobniej był to problem związany ze strefą czasową. W tym celu:

Dodaj wpis jak * * * * * datedo crontab
Usuń (lub skomentuj) dowolne zadanie TZ z crontab

Wymusza dateto uruchomienie z ustawieniem strefy czasowej wywoływacza, co oznacza demona cron . Spójrz na wynik; pokaże wewnętrzną strefę czasową, której używa cron, a zatem bardzo prawdopodobne, w której strefie czasowej chce mieć swoje pola czasowe. Jeśli masz przypisanie TZ w crontab, łatwo jest przyporządkować zmienne środowiskowe TZ do wywoływane polecenia, ale sam cron używa innej strefy czasowej . Komentując lub usuwając przypisanie TZ, unikasz tej dwuznaczności.

Zauważ też, że wszelkie zmiany w globalnych ustawieniach systemowej strefy czasowej (w tym np. / Etc / localtime) prawie na pewno wymagają co najmniej ponownego uruchomienia demona cron i ewentualnie (choć mało prawdopodobne) ponownego uruchomienia systemu, aby uzyskać pełny efekt. Edycja przypisania TZ w crontab nie powinna wymagać przeładowania demona cron, ponieważ powinna wykryć, że plik został zmieniony i załadować go automatycznie.

— CVn
źródło