Dlaczego mój crontab nie działa i jak mogę go rozwiązać?

225

To jest kanoniczne pytanie dotyczące używania cron i crontab.

Zostałeś skierowany tutaj, ponieważ społeczność jest dość pewna, że ​​odpowiedź na twoje pytanie można znaleźć poniżej. Jeśli poniżej nie znajdziesz odpowiedzi na twoje pytanie, odpowiedzi pomogą Ci zebrać informacje, które pomogą społeczności. Informacje te należy edytować w pierwotnym pytaniu.

Odpowiedź na „ Dlaczego mój crontab nie działa i jak mogę go rozwiązać? ”można zobaczyć poniżej. Dotyczy to cronsystemu z podświetlonym crontabem.

Eric Leschinski
źródło
2
To ogromny powód, dla którego crontab nie działa w AskUbuntu.
Dan Dascalescu
1
@DanDascalescu Wygląda na to, że Eric musi uzyskać więcej przedstawicieli
jestem
1
Właśnie dołączyłem do Server Fault SE (więc tylko 101 powtórzeń), ale chciałbym dać temu pytaniu -1 !! Czy to pytanie zostało zadane tylko po to, aby uzyskać przedstawiciel? @IamtheMostStupidPerson Całkowicie się z tobą zgadzam ...
Holyprogrammer
Zachodnia ideologia tych 13-letnich padawanów jest zarówno podręcznikowa, jak i oślepiająca, jak supernowa. Aby odpowiedzieć na oba pytania: tak, zrobiłem to dla przedstawiciela i tak, Eric musi uzyskać lepszą reputację. Ile potrzebuję więcej przedstawicieli? Więcej. youtu.be/IaDt9T7BF38?t=262
Eric Leschinski

Odpowiedzi:

316

Jak naprawić wszystkie problemy / problemy związane z plikiem crontab (Linux)


To jest wiki społeczności. Jeśli zauważysz coś nieprawidłowego w tej odpowiedzi lub masz dodatkowe informacje, edytuj je.


Po pierwsze, podstawowa terminologia:

  • cron (8) to demon, który wykonuje zaplanowane polecenia.
  • crontab (1) to program służący do modyfikacji plików crontab użytkownika (5).
  • crontab (5) to plik na użytkownika, który zawiera instrukcje dla cron (8).

Następnie edukacja o cronie:

Każdy użytkownik w systemie może mieć własny plik crontab. Lokalizacja plików root i crontab użytkownika zależy od systemu, ale ogólnie znajduje się poniżej /var/spool/cron.

Istnieje plik systemowy /etc/crontab, /etc/cron.dkatalog może zawierać fragmenty crontab, które są również odczytywane i uruchamiane przez cron. Niektóre dystrybucje Linuksa (np. Red Hat) również mają /etc/cron.{hourly,daily,weekly,monthly}katalogi, skrypty, które będą wykonywane co godzinę / dzień / tydzień / miesiąc, z uprawnieniami roota.

root może zawsze używać polecenia crontab; zwykli użytkownicy mogą, ale nie muszą, uzyskać dostęp. Kiedy edytujesz plik crontab za pomocą polecenia crontab -ei zapisujesz go, crond sprawdza, czy jest poprawny, ale nie gwarantuje, że plik crontab jest poprawnie utworzony. Istnieje plik o nazwie, cron.denyktóry określa, którzy użytkownicy nie mogą używać crona. Lokalizacja cron.denypliku zależy od systemu i można go usunąć, co pozwoli wszystkim użytkownikom korzystać z crona.

Jeśli komputer nie jest włączony lub demon crond nie działa, a data / godzina uruchomienia komendy minęła, crond nie nadrabia zaległości i nie wykonuje zapytań.

szczegóły crontab, jak sformułować polecenie:

Polecenie crontab jest reprezentowane przez pojedynczy wiersz. Nie można użyć \do rozszerzenia polecenia na wiele wierszy. Znak hash ( #) reprezentuje komentarz, co oznacza, że ​​cron w tym wierszu jest ignorowany. Wiodące białe znaki i puste linie są ignorowane.

Bądź BARDZO ostrożny podczas używania %znaku procentu ( ) w swoim poleceniu. O ile nie są one uciekane \%, są konwertowane na nowe linie, a wszystko po pierwszym nie-ucieczce %jest przekazywane do polecenia na standardowym wejściu.

Istnieją dwa formaty plików crontab:

  • Crontabs użytkownika

    # Example of job definition:
    # .---------------- minute (0 - 59)
    # |  .------------- hour (0 - 23)
    # |  |  .---------- day of month (1 - 31)
    # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
    # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
    # |  |  |  |  |
    # *  *  *  *  *   command to be executed
    
  • System szeroki /etc/crontabi /etc/cron.dfragmenty

    # Example of job definition:
    # .---------------- minute (0 - 59)
    # |  .------------- hour (0 - 23)
    # |  |  .---------- day of month (1 - 31)
    # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
    # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
    # |  |  |  |  |
    # *  *  *  *  * user-name  command to be executed
    

Zauważ, że ta ostatnia wymaga nazwy użytkownika. Polecenie zostanie uruchomione jako nazwany użytkownik.

Pierwsze 5 pól wiersza reprezentuje czas (s), kiedy polecenie powinno zostać uruchomione. W specyfikacji czasu można używać liczb lub, w stosownych przypadkach, nazw dni / miesięcy.

  • Pola są oddzielone spacjami lub tabulatorami.
  • Przecinek ( ,) jest używany do określenia listy, np. 1,4,6,8, co oznacza uruchomienie z 1,4,6,8.
  • Zakresy są określone za pomocą myślnika ( -) i mogą być łączone z listami, np. 1-3,9-12, co oznacza od 1 do 3, a następnie od 9 do 12.
  • /Postać może być wykorzystane do wprowadzenia np krok 2/5 co oznacza, począwszy od 2, a następnie co 5 (2,7,12,17,22 ...). Nie zawijają się do końca.
  • Gwiazdka ( *) w polu oznacza cały zakres dla tego pola (np. 0-59Dla pola minut).
  • Zakresy i kroki można łączyć np. */2Oznacza, że ​​zaczyna się od minimum dla odpowiedniego pola, a następnie co 2 np. 0 przez minuty (0,2 ... 58), 1 przez miesiące (1,3 ... 11) itd.

Debugowanie poleceń crona

Sprawdż poczte!

Domyślnie cron wyśle ​​wszelkie dane wyjściowe polecenia do użytkownika, który uruchamia polecenie jako. Jeśli nie ma danych wyjściowych, nie będzie żadnej poczty. Jeśli chcesz, aby cron wysyłał pocztę na inne konto, możesz ustawić zmienną środowiskową MAILTO w pliku crontab, np.

[email protected]
1 2 * * * /path/to/your/command

Uchwyć wyjście samodzielnie

Możesz przekierować stdout i stderr do pliku. Dokładna składnia do przechwytywania danych wyjściowych może się różnić w zależności od używanego crona powłoki. Oto dwa przykłady, które zapisują wszystkie dane wyjściowe do pliku w /tmp/mycommand.log:

1 2 * * * /path/to/your/command &>/tmp/mycommand.log
1 2 * * * /path/to/your/command >/tmp/mycommand.log 2>&1

Spójrz na dzienniki

Cron rejestruje swoje działania za pomocą syslog, który (w zależności od konfiguracji) często przechodzi do /var/log/cronlub /var/log/syslog.

W razie potrzeby można filtrować instrukcje cron za pomocą np

grep CRON /var/log/syslog 

Teraz, kiedy omówiliśmy podstawy crona, gdzie są pliki i jak z nich korzystać, spójrzmy na niektóre typowe problemy.

Sprawdź, czy cron działa

Jeśli cron nie działa, twoje polecenia nie zostaną zaplanowane ...

ps -ef | grep cron | grep -v grep

powinienem dać ci coś takiego

root    1224   1  0 Nov16 ?    00:00:03 cron

lub

root    2018   1  0 Nov14 ?    00:00:06 crond

Jeśli nie, uruchom go ponownie

/sbin/service cron start

lub

/sbin/service crond start

Mogą istnieć inne metody; użyj tego, co zapewnia twoja dystrybucja.

cron uruchamia polecenie w ograniczonym środowisku.

Dostępne zmienne środowiskowe będą prawdopodobnie bardzo ograniczone. Zwykle, dostaniesz tylko kilka zmiennych zdefiniowanych, jak $LOGNAME, $HOMEi $PATH.

Na szczególną uwagę zasługuje PATHograniczenie /bin:/usr/bin. Zdecydowana większość problemów „mój skrypt cron nie działa” spowodowana jest tą restrykcyjną ścieżką . Jeśli twoje polecenie znajduje się w innym miejscu, możesz rozwiązać to na kilka sposobów:

  1. Podaj pełną ścieżkę do swojego polecenia.

    1 2 * * * /path/to/your/command
    
  2. Podaj odpowiednią ŚCIEŻKĘ w pliku crontab

    PATH=/usr:/usr/bin:/path/to/something/else
    1 2 * * * command 
    

Jeśli twoje polecenie wymaga innych zmiennych środowiskowych, możesz je również zdefiniować w pliku crontab.

cron wykonuje polecenie za pomocą cwd == $ HOME

Niezależnie od tego, gdzie program, który wykonujesz, znajduje się w systemie plików, bieżącym katalogiem roboczym programu po uruchomieniu crona będzie katalog domowy użytkownika . Jeśli uzyskujesz dostęp do plików w swoim programie, musisz wziąć to pod uwagę, jeśli używasz ścieżek względnych lub (najlepiej) po prostu korzystasz z pełnych ścieżek wszędzie i oszczędzasz wszystkim wiele zamieszania.

Ostatnie polecenie w moim crontabie nie działa

Cron zasadniczo wymaga, aby polecenia były kończone w nowej linii. Edytuj swój crontab; przejdź do końca wiersza zawierającego ostatnie polecenie i wstaw nowy wiersz (naciśnij enter).

Sprawdź format crontab

Nie możesz użyć crontab sformatowanego przez użytkownika crontab dla / etc / crontab lub fragmentów w /etc/cron.d i vice versa. Crontab sformatowany przez użytkownika nie zawiera nazwy użytkownika w szóstej pozycji wiersza, a crontab sformatowany przez system zawiera nazwę użytkownika i uruchamia polecenie jako ten użytkownik.

Umieszczam plik w /etc/cron.{hourly,daily,weekly,monthly} i nie działa

  • Sprawdź, czy nazwa pliku nie ma rozszerzenia, patrz części run
  • Upewnij się, że plik ma uprawnienia do wykonywania.
  • Poinformuj system, z czego korzystać podczas wykonywania skryptu (np. Umieść #!/bin/shna górze)

Błędy związane z datą Cron

Jeśli twoja data została ostatnio zmieniona przez użytkownika lub aktualizację systemu, strefę czasową lub inną, wtedy crontab zacznie zachowywać się nieprawidłowo i zawierać dziwne błędy, czasem działające, a czasem nie. Jest to próba crontab, by spróbować „robić, co chcesz”, gdy czas zmienia się od spodu. Pole „minut” stanie się nieskuteczne po zmianie godziny. W tym scenariuszu akceptowane są tylko gwiazdki. Uruchom ponownie crona i spróbuj ponownie bez łączenia się z Internetem (aby data nie miała możliwości zresetowania do jednego z serwerów czasu).

Znaki procentu znowu

Aby podkreślić porady dotyczące znaków procentowych, oto przykład tego, co robi cron z nimi:

# cron entry
* * * * * cat >$HOME/cron.out%foo%bar%baz

utworzy plik ~ / cron.out zawierający 3 linie

foo
bar
baz

Jest to szczególnie uciążliwe podczas używania datepolecenia. Pamiętaj, aby uniknąć znaków procentu

* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")"
Eric Leschinski
źródło
W sekcji „ograniczona env” warto też wspomnieć, że LD_LIBRARY_PATH może również wymagać ustawienia dodatkowych katalogów na wypadek niepowodzenia zadania cron z powodu niemożności znalezienia bibliotek współużytkowanych.
DavidJ
pamiętaj, że możesz nawet napisać coś takiego: 35 1,5-23 / 2 * * * do_something zamiast 35,1,5,7,9, .. * * * Dodatkowo ten crontab.guru tłumaczy wpisy, które wprowadzasz ludzki język.
Dennis Nolte
1
Przechwytywanie danych wyjściowych nie działa dla mnie, być może z powodu powłoki sh. Myślę, że jest to bardziej przenośne: ... /path/to/your/command >/tmp/mycommand.log 2>&1
chus
to zadziałało dla mnie:sudo apt-get install postfix
jmunsch
czy zadanie crona zależy również od tego, jak ciężki jest plik? Ponieważ prowadziłem prosty świat cześć w pythonie z cronem, zadziałało. Ale mój drugi kod był nieco ciężki i zwykle działa, ale z cronem nie daje żadnych danych wyjściowych do pliku.
Devendra Bhat,
22

Debian Linux i jego pochodne (Ubuntu, Mint itp.) Mają pewne cechy szczególne, które mogą uniemożliwić wykonanie zadań crona; w szczególności pliki w /etc/cron.d, /etc/cron.{hourly,daily,weekly,monthly}musi:

  • być własnością root
  • zapisywalny tylko przez root
  • nie mogą być zapisywane przez grupę lub innych użytkowników
  • mają imię bez kropek ”. lub dowolny inny znak specjalny oprócz „-” i „_”.

Ten ostatni rani regularnie niczego niepodejrzewających użytkowników; w szczególności każdy skrypt w jednym z tych folderów nazwanych whatever.sh, mycron.py, testfile.pl, itd. będzie nie być wykonywane, kiedykolwiek.

Z mojego doświadczenia wynika, że ​​ten konkretny punkt był zdecydowanie najczęstszym powodem niewykonywania cronjobu na Debianie i instrumentach pochodnych.

Aby man cronuzyskać więcej informacji, w razie potrzeby.

wazoox
źródło
19

Jeśli Twoje cronjobs przestaną działać, sprawdź, czy hasło nie wygasło. Od tego momentu wszystkie zadania cron przestają działać.
Pojawią się wiadomości /var/log/messagespodobne do tych poniżej, które pokazują problemy z uwierzytelnianiem użytkownika:

(username) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

Munkeh72
źródło
2
Właśnie to dostałem (plik komunikatu o błędzie / var / log / syslog dla mnie). W moim przypadku pole DigitalOcean, które podczas tworzenia resetują hasło roota (opcjonalnie) na inne, i najwyraźniej dopóki tam nie wejdziesz i nie zmienisz, wszystkie zadania crona nie działają. Porażka. Naprawiono coś w stylusudo -u root passwd
rogerdpack,
12

Niezbyt częste i nieregularne harmonogramy

Cron jest uważany za bardzo prosty harmonogram, a składnia nie pozwala administratorowi na sformułowanie nieco rzadszych harmonogramów.

Rozważ następujące zadanie, które zwykle tłumaczy się jako „uruchamiane commandco 5 minut” :

*/5 * * * * /path/to/your/command

przeciw:

*/7 * * * * /path/to/your/command

który nie zawsze działa commandco 7 minut .

Pamiętaj, że /postać może zostać użyta do wprowadzenia kroku, ale kroki nie zawijają się poza koniec serii, np. */7Które pasują co 7 minut od minuty, 0-59 tj. 0,7,14,21,28,35,42,49, 56, lecz między jedną godzinę i następnym będzie tylko 4 minut pomiędzy partiami , gdy 00:56nowy cykl rozpoczyna się 01:00, 01:07itd. (i porcje nie będą działały na 01:03, 01:10, 01:17itd.).


Co zamiast tego zrobić?

Utwórz wiele partii

Zamiast pojedynczego zadania cron, utwórz wiele partii, które razem dają pożądany harmonogram.

Na przykład, aby uruchomić partię co 40 minut (00:00, 00:40, 01:20, 02:00 itd.) Utwórz dwie partie, jedną, która działa dwa razy w parzyste godziny, a druga, która działa tylko w nieparzystych godzinach:

# The following lines create a batch that runs every 40 minutes i.e.

# runs on   0:00, 0:40,        02:00, 02:40         04:00 etc to 22:40
0,40 */2 * * * /path/to/your/command

# runs on               01:20,               03:20,       etc to 23:20
20 1/2 * * * /path/to/your/command

# Combined: 0:00, 0:40, 01:20, 02:00, 02:40, 03:20, 04:00 etc.

Rzuć partie rzadziej

Zamiast uruchamiać partię co 7 minut, co trudno rozkładać na wiele partii, po prostu uruchamiaj ją co 10 minut.

Częściej uruchamiaj partie (ale zapobiegaj jednoczesnemu uruchamianiu wielu partii)

Wiele nieparzystych harmonogramów ewoluuje, ponieważ środowiska wykonawcze partii zwiększają się / zmieniają, a następnie partie są planowane z odrobiną dodatkowego marginesu bezpieczeństwa, aby zapobiec nakładaniu się i uruchamianiu kolejnych serii tej samej partii.

Zamiast tego, pomyśl inaczej i stwórz cronjob, który z wdziękiem zawiedzie, gdy poprzednie uruchomienie jeszcze się nie zakończyło, ale będzie działać inaczej. Zobacz te pytania i odpowiedzi :

* * * * * /usr/bin/flock -n /tmp/fcj.lockfile /usr/local/bin/frequent_cron_job 

To prawie natychmiast rozpocznie nowy przebieg po zakończeniu poprzedniego uruchomienia / usr / local / bin / Frequent_cron_job.

Zacznij partie częściej (ale z wdziękiem wychodź, gdy warunki nie są odpowiednie)

Ponieważ składnia cron jest ograniczona, możesz zdecydować o umieszczeniu bardziej złożonych warunków i logiki w samym zadaniu wsadowym (lub w skrypcie opakowującym wokół istniejącego zadania wsadowego). Dzięki temu możesz wykorzystać zaawansowane możliwości swoich ulubionych języków skryptowych, komentować kod i zapobiegać trudnym do odczytania konstrukcjom w samym wpisie crontab.

W bashu seven-minute-jobwyglądałoby to mniej więcej tak:

#!/bin/bash
# seven-minute-job
# This batch will only run when 420 seconds (7 min) have passed
# since the file /tmp/lastrun was either created or updated

if [ ! -f /tmp/lastrun ] ; then
    touch /tmp/lastrun
fi

if [ $(( $(date +%s) - $(date -r /tmp/lastrun +%s) )) -lt 420 ] ; then
     # The minimum interval of 7 minutes between successive batches hasn't passed yet.
    exit 0
fi

####  Start running your actual batch job below

/path/to/your/command

#### actual batch job is done, now update the time stamp
date > /tmp/lastrun
#EOF

Które możesz następnie bezpiecznie (próbować) uruchomić co minutę:

* * * * * /path/to/your/seven-minute-job

Odmienny, ale podobny problem by zaplanować partii do uruchomienia w pierwszy poniedziałek każdego miesiąca (lub w drugą środę) itd Wystarczy zaplanować partii do uruchomienia w każdy poniedziałek i wyjście gdy data nie jest ani między 1 st lub 7 th i dzień tygodnia nie jest poniedziałkiem.

#!/bin/bash
# first-monday-of-the-month-housekeeping-job

# exit if today is not a Monday (and prevent locale issues by using the day number) 
if [ $(date +%u) != 1 ] ; then
  exit 0
fi

# exit if today is not the first Monday
if [ $(date +%d) -gt 7 ] ; then
  exit 0
fi

####  Start running your actual batch job below

/path/to/your/command

#EOF

Które możesz następnie bezpiecznie (próbować) uruchomić w każdy poniedziałek:

0 0 * * 1 /path/to/your/first-monday-of-the-month-housekeeping-job

Nie używaj crona

Jeśli Twoje potrzeby są złożone, możesz rozważyć użycie bardziej zaawansowanego produktu, który jest zaprojektowany do uruchamiania złożonych harmonogramów (rozproszonych na wielu serwerach) i który obsługuje wyzwalacze, zależności zadań, obsługę błędów, ponawianie prób i monitorowanie itp. Żargonem branżowym byłoby „przedsiębiorstwo „ planowanie zadań i / lub„ automatyzacja obciążenia ”.

HBruijn
źródło
8

Specyficzne dla PHP

Jeśli masz jakieś zadanie crona, takie jak:

php /bla/bla/something.php >> /var/logs/somelog-for-stdout.log

A w przypadku błędów oczekuj, że zostaną do Ciebie wysłane, ale nie robią tego - sprawdź to.

PHP domyślnie nie wysyła błędów do STDOUT. @ patrz https://bugs.php.net/bug.php?id=22839

Aby to naprawić, dodaj w pliku cli`s php.ini lub w linii (lub w bashu dla PHP):

  • - zdefiniuj display_startup_errors = 1
  • - zdefiniować display_errors = 'stderr'

1. ustawienie pozwoli ci mieć takie fatale jak „Ups pamięci”, a drugie - przekieruje ich wszystkich do STDERR. Dopiero po tym, jak będziesz mógł spać spokojnie, wszystko zostanie wysłane na pocztę użytkownika root, a nie tylko zalogowane.

gaRex
źródło
2
Ten raport o błędach został zamknięty w 2007 r., A status poprawki został dodany do gałęzi PHP 5.2+. Czy na pewno jest to potrzebne? Właśnie wypróbowałem PHP 5.4 i wydaje się, że działa dobrze. (Jest jednak nadal potrzebny w PHP 4).
Xeoncross,
@Xeoncross patrz data odpowiedzi :)
gaRex
1
Tak, to mnie pomyliło, odkąd odpowiedziałeś w 2013 roku, a bilet wrócił w '07.
Xeoncross,
0

Dodawanie moją odpowiedź stąd pod kątem kompletności i dodanie innego potencjalnie pomocne zasobu:

cronUżytkownik ma inny $PATHniż zrobić:

Częstym problemem, jaki użytkownicy stawiają przy crontabwpisach, jest to, że zapominają, że crondziałają w inny sposób environmentniż jako zalogowani użytkownicy. Na przykład użytkownik tworzy program lub skrypt w swoim $HOMEkatalogu i wprowadza następującą komendę, aby go uruchomić:

$ ./certbot ... 

Polecenie działa idealnie z jego wiersza poleceń. Następnie użytkownik dodaje to polecenie do swojego crontab, ale stwierdza, że ​​to nie działa:

*/10 * * * * ./certbot ....

Przyczyną niepowodzenia w tym przypadku jest ./inna lokalizacja dla cronużytkownika niż dla zalogowanego użytkownika. Oznacza to, że environmentjest inaczej! ŚCIEŻKA jest częścią environmenti zwykle jest inna dla cronużytkownika. Problem komplikuje to, że environmentfor cronnie jest taki sam dla wszystkich dystrybucji * nix i istnieje wiele wersjicron

Prostym rozwiązaniem tego konkretnego problemu jest podanie cronużytkownikowi pełnej specyfikacji ścieżki we crontabwpisie:

0 22 * * * /path/to/certbot .....

Jaki jest cronużytkownik environment?

W niektórych przypadkach możemy potrzebować poznać pełną environmentspecyfikację cronw naszym systemie (lub możemy być po prostu ciekawi). Co jest environmentdla cronużytkownika i czym różni się od naszego? Co więcej, może być konieczne poznanie environmentinnego cronużytkownika - rootna przykład ... z czego korzysta rootużytkownik ? Jednym ze sposobów, aby się tego nauczyć, jest poproszenie o powiedzenie nam: environmentcroncron

  1. Utwórz skrypt powłoki w katalogu domowym ( ~/) w następujący sposób (lub w wybranym edytorze):
$ nano ~/envtst.sh
  1. Wpisz następujące dane w edytorze po dostosowaniu do systemu / użytkownika:
#!/bin/sh 
/bin/echo "env report follows for user "$USER >> /home/you/envtst.sh.out 
/usr/bin/env >> /home/you/envtst.sh.out 
/bin/echo "env report for user "$USER" concluded" >> /home/you/envtst.sh.out
/bin/echo " " >> /home/you/envtst.sh.out
  1. Zapisz plik, zamknij edytor i ustaw uprawnienia pliku jako wykonywalne.
$ chmod a+rx ~/envtst.sh
  1. Uruchom właśnie utworzony skrypt i przejrzyj dane wyjściowe w /home/you/envtst.sh.out. Dane wyjściowe pokażą twoje aktualne środowisko, gdy $USERjesteś zalogowany jako:
$ ./envtst.sh $$ cat /home/you/envtst.sh.out
  1. Otwórz crontabdo edycji:
$ crontab -e -u root
  1. Wpisz następujący wiersz u dołu crontab:
* * * * *  /home/you/envtst.sh >> /home/you/envtst.sh.err 2>&1

ODPOWIEDŹ: Plik wyjściowy /home/you/envtst.sh.outbędzie zawierał listę environmentdla „użytkownika root cron”. Gdy się o tym dowiesz, odpowiednio dostosuj swój crontabwpis.

Nie mogę określić harmonogramu, którego potrzebuję we crontabwpisie:

Wpis harmonogramu dla crontabjest oczywiście zdefiniowany w man crontab, i powinieneś to przeczytać. Jednak czytanie man crontabi rozumienie harmonogramu to dwie różne rzeczy. A próby i błędy w specyfikacji harmonogramu mogą stać się bardzo nużące. Na szczęście istnieje zasób, który może pomóc: guru crontab. . Wprowadź specyfikację harmonogramu, a objaśni harmonogram w prostym języku angielskim.

Wreszcie, ryzykując zwolnieniem z jedną z innych odpowiedzi tutaj, nie daj się złapać w pułapkę myślenia, że ​​jesteś ograniczony do jednego crontabwpisu, ponieważ masz jedno zadanie do zaplanowania. Możesz użyć tyle crontabwpisów, ile potrzebujesz, aby uzyskać potrzebny harmonogram.

Seamus
źródło