Dlaczego skrypty crontab nie działają?

459

Często skrypty crontab nie są wykonywane zgodnie z harmonogramem lub zgodnie z oczekiwaniami. Jest wiele powodów:

  1. niepoprawna notacja crontab
  2. problem z uprawnieniami
  3. zmienne środowiskowe

Ta wiki społeczności ma na celu agregację najważniejszych przyczyn, dla których crontab skryptów nie jest wykonywanych zgodnie z oczekiwaniami. Napisz każdy powód w osobnej odpowiedzi.

Podaj jeden powód jednej odpowiedzi - szczegóły, dlaczego nie jest ona wykonywana - i napraw (y) z tego jednego powodu.

Napisz tylko problemy związane z cronem, np. polecenia, które są wykonywane zgodnie z oczekiwaniami z powłoki, ale są wykonywane błędnie przez cron.

    
zadawane Adam Matan 08.05.2017, 20:15
źródło

46 odpowiedzi

435

Różne środowisko

Cron przekazuje minimalny zestaw zmiennych środowiskowych do twoich zadań. Aby zobaczyć różnicę, dodaj pozorowane zadanie:

* * * * * env > /tmp/env.output

Poczekaj na utworzenie /tmp/env.output , a następnie usuń zadanie ponownie. Teraz porównaj zawartość /tmp/env.output z wynikiem env uruchomionym w twoim zwykłym terminalu.

Typowym "groszkiem" jest tutaj inna zmienna środowiskowa PATH . Może twój skrypt cron używa polecenia somecommand znalezionego w /opt/someApp/bin , które dodałeś do PATH w /etc/environment ? cron ignoruje PATH z tego pliku, więc uruchomienie somecommand ze skryptu zakończy się niepowodzeniem po uruchomieniu z cronem, ale działa po uruchomieniu w terminalu. Warto zauważyć, że zmienne z /etc/environment będą przekazywane do zadań cron, po prostu nie zmienne cron samo ustawia się samodzielnie, takie jak PATH .

Aby to obejść, wystarczy ustawić własną zmienną PATH u góry skryptu. E.g.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Niektórzy wolą zamiast tego używać bezwzględnych ścieżek do wszystkich poleceń. Polecam przeciw temu. Zastanów się, co się stanie, jeśli chcesz uruchomić skrypt w innym systemie, a w tym systemie polecenie jest w /opt/someAppv2.2/bin . Musiałbyś przejść przez cały skrypt zastępując /opt/someApp/bin przez /opt/someAppv2.2/bin zamiast po prostu zrobić małą edycję w pierwszym wierszu skryptu.

Możesz także ustawić zmienną PATH w pliku crontab, która będzie miała zastosowanie do wszystkich zadań crona. E.g.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root
    
odpowiedział geirha 27.02.2018, 19:47
źródło
295

Moje najlepsze miejsce: Jeśli zapomnisz dodać znak nowej linii na końcu pliku crontab . Innymi słowy, plik crontab powinien kończyć się pustym wierszem.

Poniżej znajduje się odpowiednia sekcja na stronach man dla tego wydania ( man crontab , a następnie przejdź do końca):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)
    
odpowiedział user4124 02.02.2011, 21:32
źródło
126

Demona Cron nie działa. Naprawdę spieprzyłem to kilka miesięcy temu.

Typ:

pgrep cron 

Jeśli nie widzisz numeru, to cron nie działa. sudo /etc/init.d/cron start może być użyty do uruchomienia crona.

EDYCJA: Zamiast wywoływać skrypty init za pośrednictwem /etc/init.d, skorzystaj z usługi narzędzie, np.

sudo service cron start
    
odpowiedział 4 revs, 4 users 38%user6019 26.01.2012, 11:57
źródło
85

Nazwy plików skryptów w cron.d/ , cron.daily/ , cron.hourly/ , itp., nie powinny zawierać kropki ( . ), w przeciwnym razie run-parts ich pominie.

Patrz run-parts (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Tak więc, jeśli masz skrypt cron backup.sh , analyze-logs.pl w katalogu cron.daily/ , najlepiej usunąć nazwy rozszerzeń.

    
odpowiedział Xiè Jìléi 10.01.2017, 16:20
źródło
56

W wielu środowiskach cron wykonuje polecenia używając sh , a wiele osób zakłada, że użyje bash .

Sugestie do przetestowania lub naprawienia tego polecenia powodującego niepowodzenie:

  • Spróbuj uruchomić polecenie w sh , aby sprawdzić, czy działa
  • Zawiń polecenie w podpowłoce bash, aby upewnić się, że zostanie uruchomione w bash:
    bash -c "mybashcommand"
  • Powiedz cronowi, aby uruchamiał wszystkie polecenia w bashu, ustawiając powłokę u góry twojego crontaba:
    SHELL=/bin/bash
  • Jeśli polecenie jest skryptem, upewnij się, że skrypt zawiera kod shebang:
    #!/bin/bash
odpowiedział Ian Mackinnon 25.06.2011, 21:30
źródło
34

Miałem pewne problemy ze strefami czasowymi. Cron działał ze świeżą strefą czasową instalacji. Rozwiązaniem było ponowne uruchomienie cron:

sudo service cron restart
    
odpowiedział luissquall 07.02.2012, 15:49
źródło
29

Jeśli twoje polecenie crontab ma w sobie symbol % , cron próbuje go zinterpretować. Więc jeśli używałeś jakiegokolwiek polecenia z % (np. Specyfikacją formatu do polecenia date), będziesz musiał uciec z tego.

To i inne dobre rzeczy tutaj:
link

    
odpowiedział JMS 26.08.2012, 08:59
źródło
28

Ścieżka bezwzględna powinna być używana dla skryptów:

Na przykład należy użyć /bin/grep zamiast grep :

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Zamiast:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Jest to szczególnie trudne, ponieważ to samo polecenie będzie działać, gdy zostanie wykonane z powłoki. Powodem jest to, że cron nie ma tej samej zmiennej środowiskowejPATH co użytkownik.

    
odpowiedział Adam Matan 24.01.2011, 11:02
źródło
24

Jest również możliwe, że hasło użytkownika wygasło. Nawet hasło roota może wygasnąć. Możesz tail -f /var/log/cron.log , a zobaczysz, że cron nie działa z błędem. Możesz ustawić hasło, aby nigdy nie wygasało: passwd -x -1 <username>

W niektórych systemach (Debian, Ubuntu) logowanie do crona nie jest domyślnie włączone. W /etc/rsyslog.conf lub /etc/rsyslog.d/50-default.conf wiersz:

# cron.*                          /var/log/cron.log

należy edytować ( sudo nano /etc/rsyslog.conf ) odkomentowane do:

cron.*                          /var/log/cron.log

Następnie musisz zrestartować rsyslog przez

/etc/init.d/rsyslog restart

lub

service rsyslog restart 

Źródło: Włącz rejestrowanie crontab w systemie Debian Linux

W niektórych systemach (Ubuntu) osobny plik logowania dla crona nie jest domyślnie włączony, ale logi związane z cron pojawiają się w pliku syslog. Można użyć

cat /var/log/syslog | grep cron

, aby wyświetlić wiadomości związane z cronem.

    
odpowiedział 6 revs, 5 users 34%unknown 11.05.2016, 12:48
źródło
22

Cron wywołuje skrypt, który nie jest wykonywalny.

Uruchomienie chmod +x /path/to/scrip powoduje, że skrypt staje się wykonywalny i powinien rozwiązać ten problem.

    
odpowiedział jet 26.01.2011, 19:24
źródło
16

Jeśli twój cronjob wywołuje aplikacje GUI, musisz powiedzieć im, jakiego DISPLAY powinni użyć.

Przykład: Firefox uruchamia się z cronem.

Twój skrypt powinien gdzieś zawierać export DISPLAY=:0 .

    
odpowiedział andrew 26.07.2012, 17:46
źródło
14

Problemy z uprawnieniami są dość powszechne, obawiam się.

Zauważ, że powszechnym sposobem obejścia tego problemu jest wykonanie wszystkiego za pomocą crontab root, co czasami jest naprawdę złym pomysłem. Ustawienie odpowiednich uprawnień jest zdecydowanie w dużej mierze pomijanym problemem.

    
odpowiedział user9521 26.01.2011, 16:53
źródło
13

Niepewne uprawnienie do tabeli crona

Tabela cron jest odrzucona jeśli jego pozwolenie jest niepewne

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

Problem został rozwiązany za pomocą

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
    
odpowiedział John Peterson 15.06.2013, 05:12
źródło
11

Skrypt jest wrażliwy na lokalizację. Jest to związane z tym, że zawsze używamy bezwzględnych ścieżek w skrypcie, ale nie do końca takich samych. Twoje zadanie cron może wymagać cd do określonego katalogu przed uruchomieniem, np. zadanie rake w aplikacji Rails może wymagać od root'a aplikacji Rake, aby znaleźć prawidłowe zadanie, nie wspominając o odpowiedniej konfiguracji bazy danych itp.

Tak więc wpis crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

byłoby lepsze jak

23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

Lub, aby zachować prostszy i mniej kruchy wpis crontab:

23 3 * * * /home/<user>/scripts/session-purge.sh

z następującym kodem w /home/<user>/scripts/session-purge.sh :

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
    
odpowiedział pjmorse 29.11.2011, 16:20
źródło
10

Specyfikacje Crontab , które działały w przeszłości , mogą zostać złamane podczas przenoszenia z jednego pliku crontab na inny. Czasami powodem jest przeniesienie specyfikacji z pliku crontab systemu do pliku crontab użytkownika lub odwrotnie.

Format specyfikacji zadania cron różni się w zależności od plików crontab użytkowników (/ var / spool / cron / nazwa_użytkownika lub / var / spool / cron / crontabs / nazwa_użytkownika) oraz crontabów systemu ( /etc/crontab i plików w /etc/cron.d ).

System crontab ma dodatkowe pole 'user' tuż przed uruchomieniem polecenia.

To spowoduje błędy z określeniem rzeczy takich jak george; command not found po przeniesieniu polecenia z /etc/crontab lub pliku w /etc/cron.d do pliku crontab użytkownika.

Odwrotnie, cron będzie wyświetlał błędy, takie jak /usr/bin/restartxyz is not a valid username lub podobne, gdy wystąpi odwrotność.

    
odpowiedział pbr 25.10.2013, 17:04
źródło
9

skrypt cron wywołuje polecenie z opcją --verbose

Miałem skrypt cron zawodzić na mnie, ponieważ byłem w autopilocie podczas pisania skryptu i włączono opcję --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

Skrypt działał poprawnie podczas wykonywania z powłoki, ale nie działał podczas uruchamiania z crontab, ponieważ pełne wyjście przechodzi na standardowe wyjście, gdy uruchamiane jest z powłoki, ale nigdzie, gdy uruchamiane jest z crontab. Łatwa naprawa, aby usunąć "v":

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
    
odpowiedział Aaron Peart 03.06.2012, 08:59
źródło
7

Najczęstszy powód, dla którego widziałem, że cron zawodzi w nieprawidłowo określonym harmonogramie. Zaleca się określenie zadania zaplanowanego na godzinę 23:15 jako 30 23 * * * zamiast * * 11 15 * lub 11 15 * * * . Dzień tygodnia dla zadań po północy również się myli M-F to 2-6 po północy nie 1-5 . Określone daty są zwykle problemem, ponieważ rzadko je używamy. * * 3 1 * nie jest 3 marca.

Jeśli praca z różnymi platformami przy użyciu nieobsługiwanych opcji, takich jak 2/3 w specyfikacji czasu, może również spowodować awarie. Jest to bardzo przydatna opcja, ale nie jest powszechnie dostępna. Wystąpiłem również w przypadku problemów, które będą zawierały listy takie jak 1-5 lub 1,3,5 .

Używanie niewykwalifikowanych ścieżek również powoduje problemy. Domyślną ścieżką jest zwykle /bin:/usr/bin , więc będą działać tylko standardowe polecenia. Te katalogi zwykle nie mają żądanego polecenia. Dotyczy to również skryptów używających niestandardowych poleceń. Inne zmienne środowiskowe również mogą nie być dostępne.

Przemieszanie istniejącego crontaba całkowicie spowodowało problemy. Teraz ładuję z kopii pliku. Można go odzyskać z istniejącego pliku crontab, używając crontab -l , jeśli zostanie on sparowany. Zachowuję kopię pliku crontab w ~ / bin. Jest on komentowany i kończy się na linii # EOF . Jest to ponownie ładowane codziennie z wpisu crontab, takiego jak:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

Powyższe polecenie przeładowania polega na wykonywalnym pliku crontab ze ścieżką hukującą crontab. Niektóre systemy wymagają uruchomienia polecenia crontab w komendzie i określenia pliku. Jeśli katalog jest udostępniony w sieci, często używam crontab.$(hostname) jako nazwy pliku. To ostatecznie poprawi przypadki, w których niewłaściwy plik crontab jest ładowany na niewłaściwym serwerze.

Korzystanie z pliku zapewnia kopię zapasową zawartości pliku crontab i pozwala na tymczasowe zmiany (jedyny czas, kiedy używam crontab -e ) do automatycznego wycofania. Dostępne są nagłówki, które pomagają uzyskać poprawne parametry planowania. Dodałem je, gdy niedoświadczeni użytkownicy edytują plik crontab.

Rzadko natrafiłem na polecenia wymagające wprowadzenia użytkownika. Te nie działają pod crontabem, chociaż niektóre będą działać z przekierowaniem wejścia.

    
odpowiedział BillThor 01.02.2011, 19:37
źródło
6

Jeśli uzyskujesz dostęp do konta za pomocą kluczy SSH, możesz zalogować się do konta, ale nie zauważysz, że hasło na koncie jest zablokowane (np. z powodu wygasłych lub nieprawidłowych prób podania hasła)

Jeśli system używa PAM, a konto jest zablokowane, może to uniemożliwić uruchomienie cronjob. (Testowałem to na Solarisie, ale nie na Ubuntu)

Możesz znaleźć takie wiadomości w / var / adm / messages:

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Wszystko, co musisz zrobić, to uruchomić:

# passwd -u <USERNAME>

jako root, aby odblokować konto, a crontab powinien znów działać.

    
odpowiedział JohnGH 24.10.2012, 09:22
źródło
4

Jeśli masz takie polecenie:

* * * * * /path/to/script >> /tmp/output

i to nie działa i nie widać żadnych wyników, niekoniecznie oznacza to, że cron nie działa. Skrypt może zostać złamany, a wyjście będzie stderr , które nie zostanie przekazane do / tmp / output. Sprawdź, czy tak nie jest, przechwytując również to wyjście:

* * * * * /path/to/script >> /tmp/output 2>&1

, aby zobaczyć, czy to pomoże Ci złapać problem.

    
odpowiedział Philluminati 18.04.2018, 20:26
źródło
3

W moim przypadku cron i crontab mieli różnych właścicieli.

NIE działa Mam to:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Zasadniczo musiałem uruchomić cron-config i poprawnie odpowiedzieć na pytania. Jest taki moment, w którym muszę podać moje hasło użytkownika Win7 dla mojego konta "User". Z czytania zrobiłem, wygląda na to, że jest to potencjalny problem z bezpieczeństwem, ale jestem jedynym administratorem w jednej sieci domowej, więc zdecydowałem, że wszystko jest w porządku.

Oto sekwencja poleceń, która uruchomiła mnie:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $
    
odpowiedział KiloOne 10.12.2015, 10:20
źródło
3

Pisałem skrypt powłoki instalacyjnej, który tworzy inny skrypt do usuwania starych danych transakcji z bazy danych. W ramach zadania musiano skonfigurować codzienne zadanie cron w dowolnym momencie, gdy obciążenie bazy danych było niskie.

Stworzyłem plik mycronjob z harmonogramem cron, nazwą użytkownika & amp; polecenie i skopiowane do katalogu /etc/cron.d . Moje dwie gry:

  1. mycronjob plik musiał być własnością root'a, aby uruchomić
  2. Musiałem ustawić uprawnienia do pliku na 644 - 664 nie uruchamiał.

Problem z uprawnieniami pojawi się w /var/log/syslog jako coś podobnego do:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

Pierwszy wiersz odnosi się do pliku /etc/crontab , a później do pliku umieszczonego pod /etc/cront.d .

    
odpowiedział Izik Golan 24.04.2017, 21:53
źródło
3

=== Alert Docker ===

Jeśli używasz okna dokowanego,

Myślę, że należy dodać, że nie udało mi się uruchomić cronu w tle.

Aby uruchomić zadanie cron w kontenerze, użyłem nadzoru i uruchomiłem cron -f razem z innym procesem.

Edytuj: Kolejny problem - nie udało mi się też uruchomić go przy uruchomieniu kontenera z siecią HOST. Zobacz także ten problem: link

    
odpowiedział AlonL 20.05.2015, 17:48
źródło
2

Linia napisana w sposób, którego crontab nie rozumie. To musi być poprawnie napisane. Oto CrontabHowTo .

    
odpowiedział Kangarooo 02.02.2011, 20:52
źródło
2

Daemon Cron może działać, ale nie działa. Spróbuj ponownie uruchomić cron:

sudo /etc/init.d/cron restart
    
odpowiedział Phil Dodd 25.11.2011, 00:20
źródło
2

Zapisywanie do crona poprzez "crontab -e" z argumentem nazwa_użytkownika w wierszu. Widziałem przykłady użytkowników (lub sysadmins) piszących swoje skrypty powłoki i nie rozumiejących, dlaczego nie automatyzują. Argument "user" istnieje w / etc / crontab, ale nie w plikach zdefiniowanych przez użytkownika. więc na przykład twój osobisty plik mógłby wyglądać mniej więcej tak:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

podczas gdy / etc / crontab będzie:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

A więc, dlaczego zrobiłbyś to drugie? Cóż, w zależności od tego, jak chcesz ustawić swoje uprawnienia, może to stać się bardzo zawiłe. Napisałem skrypty, aby zautomatyzować zadania dla użytkowników, którzy nie rozumieją zawiłości, lub nie chcą zawracać sobie głowy hańbą. Ustawiając uprawnienia na --x------ , mogę uczynić skrypt wykonywalny bez możliwości odczytu (i być może przypadkowego). Mogę jednak chcieć uruchomić to polecenie z kilkoma innymi z jednego pliku (co ułatwi utrzymanie), ale upewnij się, że plik wyjściowy pliku ma przypisanego prawowitego właściciela. Czyniąc tak (przynajmniej w Ubuntu 10.10) łamie się zarówno niemożność odczytania pliku, jak i wykonania, plus wspomniany wcześniej problem z umieszczaniem kropek w / etc / crontab (który, co zabawne, nie powoduje błędu podczas przechodzenia przez crontab -e ).

Jako przykład, widziałem wystąpienia sudo crontab -e używane do uruchamiania skryptu z uprawnieniami root'a, z odpowiednim chown username file_output w skrypcie powłoki. Niechlujny, ale działa. IMHO, bardziej elegancką opcją jest umieszczenie go w /etc/crontab z zadeklarowaną nazwą użytkownika i odpowiednimi uprawnieniami, więc file_output trafi w odpowiednie miejsce i właściciela.

    
odpowiedział Mange 12.06.2012, 19:42
źródło
2

Rozwijając to, co Aaron Peart wspomniał o trybie szczegółowym, czasami skrypty nie w trybie szczegółowym będą inicjowane, ale nie kończą się, jeśli domyślnym zachowaniem dołączonego polecenia jest wyprowadzenie linii lub więcej na ekranie po uruchomieniu proc. Na przykład napisałem skrypt zapasowy do naszego intranetu, który używał curl, narzędzia, które pobiera lub przesyła pliki na zdalne serwery i jest bardzo przydatny, jeśli dostęp do wspomnianych plików zdalnych można uzyskać tylko za pośrednictwem protokołu HTTP. Używanie "curl link " powodowało, że napisany przeze mnie skrypt zawiesił się i nigdy się nie zakończył, ponieważ wypluł znak nowej linii, a następnie linię postępu. Musiałem użyć cichej flagi (-s), aby nie przekazywać żadnych informacji i pisać w moim własnym kodzie, aby obsłużyć, jeśli nie udało się pobrać pliku.

    
odpowiedział Mange 12.06.2012, 22:06
źródło
2

Chociaż możesz zdefiniować zmienne środowiskowe w swoich ustawieniach frontalnych, nie jesteś w skrypcie powłoki. Konstrukcje takie jak te nie będą działać:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Wynika to z faktu, że zmienne nie są interpretowane w trybie "front": wszystkie wartości są pobierane zaśmiecanie. I to samo dotyczy pominięcia nawiasów. Więc twoje polecenia nie będą działać, a twoje pliki dziennika nie zostaną zapisane ...

Zamiast tego musisz zdefiniować wszystkie swoje zmienne środowiskowe prosto:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
    
odpowiedział Alexandre 07.06.2013, 11:13
źródło
2

Gdy zadanie jest uruchamiane w cron, standardowe wejście jest zamknięte. Programy, które działają inaczej w zależności od tego, czy standardowe wejście jest dostępne, będą zachowywać się inaczej między sesją powłoki a cronem.

Przykładem jest program goaccess do analizy plików dziennika serwera WWW. To NIE działa w cron:

goaccess -a -f /var/log/nginx/access.log > output.html

i goaccess pokazuje stronę pomocy zamiast tworzenia raportu. W powłoce można to odtworzyć za pomocą

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

Poprawka dla goaccess polega na tym, aby odczytywał dziennik ze stdin zamiast odczytywać z pliku, więc rozwiązaniem jest zmiana wpisu crontab na

cat /var/log/nginx/access.log | goaccess -a > output.html
    
odpowiedział Martijn de Milliano 09.08.2013, 22:27
źródło
2

Na moich serwerach RHEL7 byłyby uruchamiane zadania root cron, ale zadania użytkownika by nie działały. Znalazłem, że bez katalogu domowego, zadania nie będą działać (ale zobaczysz dobre błędy w / var / log / cron). Kiedy stworzyłem katalog domowy, problem został rozwiązany.

    
odpowiedział Dennis Parslow 02.02.2017, 22:29
źródło
2

Jeśli edytowałeś swój plik crontab za pomocą edytora Windows (przez sambę lub coś podobnego) i został on zastąpiony nowymi znakami \ n \ r lub po prostu \ r, cron nie uruchomi się.

Ponadto, jeśli używasz /etc/cron.d/* i jeden z tych plików ma w sobie \ r, cron przejdzie przez pliki i zatrzyma się, gdy trafi na zły plik. Nie masz pewności, czy to jest problem?

Użyj:

od -c /etc/cron.d/* | grep \r
    
odpowiedział Doug 20.04.2017, 03:38
źródło

Przeczytaj inne pytania na temat tagów