Proč crontab skripty nefungují?

456

Skriptycrontab často nejsou spuštěny podle plánu nebo podle očekávání. Existuje mnoho důvodů:

  1. špatná poznámka crontab
  2. problém s oprávněními
  3. proměnné prostředí

Tato wiki komunity má za cíl shromáždit nejčastější důvody, proč skriptycrontab nejsou spuštěny podle očekávání. Napište každý důvod do samostatné odpovědi.

Zadejte jeden důvod pro každou odpověď - podrobnosti o tom, proč to není provedeno - a opravte z tohoto důvodu.

Napište pouze cron-specifické problémy, např. příkazy, které se spouštějí podle očekávání z shellu, ale chybu provedou cron.

    
dané Adam Matan 08.05.2017 20:15

46 odpovědí

431

Různé prostředí

Cron předává minimální sadu proměnných prostředí vašim úlohám. Chcete-li vidět rozdíl, přidejte fiktivní úlohu takto:

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

Počkejte, až bude vytvořen/tmp/env.output, a potom znovu odeberte úlohu. Nyní porovnejte obsah/tmp/env.output s výstupemenv ve svém běžném terminálu.

Obvyklá "gotcha" zde je proměnná prostředíPATH odlišná. Možná váš cron skript používá příkazsomecommand nalezený v/opt/someApp/bin, který jste přidali doPATH v/etc/environment? cron ignorujePATH z tohoto souboru, takže runnningsomecommand ze skriptu selže při spuštění s cronem, ale pracuje při spuštění v terminálu. Stojí za to poznamenat, že proměnné z/etc/environment budou předány na úlohy cron, prostě ne proměnné cron se samy nastaví, napříkladPATH.

Chcete-li se dostat kolem toho, stačí nastavit vlastní proměnnouPATH v horní části skriptu. Např.

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

# rest of script follows

Někteří raději používají místo toho absolutní cesty ke všem příkazům. Doporučuji to proti tomu. Zvažte, co se stane, pokud chcete spustit skript na jiném systému, a v tomto systému je příkaz v/opt/someAppv2.2/bin namísto toho. Budete muset projít celým skriptem nahradit/opt/someApp/bin s/opt/someAppv2.2/bin místo toho, že byste jen malou úpravu na prvním řádku skriptu.

Proměnnou PATH můžete také nastavit v souboru crontab, který se bude vztahovat na všechny úlohy cron. Např.

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

15 1 * * * backupscript --incremental /home /root
    
odpověděl geirha 27.02.2018 19:47
292

Můj top gotcha: Pokud zapomenete přidat nový řádek na konec souborucrontab. Jinými slovy by měl soubor crontab skončit prázdným řádkem.

Níže je příslušná část v manuálových stránkách tohoto problému (man crontab a pak přeskočte na konec):

   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)
    
odpověděl user4124 02.02.2011 21:32
125

Cron démon nefunguje. Opravdu jsem se s tím před několika měsíci zklamal.

Typ:

pgrep cron 

Pokud nevidíte žádné číslo, potom cron neběží. % c_kde% lze použít ke spuštění cronu.

EDIT: Spíše než vyvolání skriptů init pomocí /etc/init.d, použijte službu např.

sudo service cron start
    
odpověděl 4 revs, 4 users 38%user6019 26.01.2012 11:57
83

Názvy souborů skriptů vcron.d/,cron.daily/,cron.hourly/ atd. by neměly obsahovat tečku (.), jinak budou run-parts přeskočit.

Podívejte se na části běhu (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_-]+$).

Pokud tedy máte cron skriptbackup.sh,analyze-logs.pl vcron.daily/ adresáři, nejlépe odebrat názvy rozšíření.

    
odpověděl Xiè Jìléi 10.01.2017 16:20
56

V mnoha prostředích cron provádí příkazy pomocísh, zatímco mnoho lidí předpokládá, že použijebash.

Návrhy pro otestování nebo opravu chybějícího příkazu:

  • Zkuste spustit příkaz vsh, abyste zjistili, zda funguje
  • Zabalte příkaz v bash subshell a ujistěte se, že se dostane do běhu bash:
    bash -c "mybashcommand"
  • Řekněte programu cron spuštění všech příkazů v bash nastavením shellu v horní části vašeho crontab:
    SHELL=/bin/bash
  • Pokud je příkaz skript, ujistěte se, že skript obsahuje shebang:
    #!/bin/bash
odpověděl Ian Mackinnon 25.06.2011 21:30
34

Měl jsem nějaké problémy s časovými pásmy. Cron běžel s čerstvým časovým pásmem instalace. Řešením bylo restartovat cron:

sudo service cron restart
    
odpověděl luissquall 07.02.2012 15:49
29

Pokud váš příkaz crontab obsahuje symbol% ​​co_kde%, cron se pokusí interpretovat. Takže pokud používáte libovolný příkaz s% v něm (např. Specifikace formátu k datovému příkazu), budete muset uniknout.

To a další dobré chyby zde:
Odkaz

    
odpověděl JMS 26.08.2012 08:59
28

Absolutní cesta by měla být použita pro skripty:

Například byste měli použít/bin/grep namístogrep:

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

Namísto:

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

Toto je obzvláště obtížné, protože stejný příkaz bude fungovat při spuštění ze shellu. Důvodem je to, žecron nemá stejnou proměnnou prostředíPATH jako uživatel.

    
odpověděl Adam Matan 24.01.2011 11:02
23

Je také možné, že uživatelské heslo vypršela. Dokonce i heslo uživatele root může vypršet. Můžetetail -f /var/log/cron.log a uvidíte cron fail s vypršením platnosti hesla. Heslo můžete nastavit tak, aby nikdy neuplynulo:passwd -x -1 <username>

V některých systémech (Debian, Ubuntu) protokolování pro cron není ve výchozím nastavení povoleno. V řádku /etc/rsyslog.conf nebo /etc/rsyslog.d/50-default.conf řádka:

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

by mělo být editováno (sudo nano /etc/rsyslog.conf) neodpovídá na:

cron.*                          /var/log/cron.log

Poté musíte restartovat rsyslog přes

/etc/init.d/rsyslog restart

nebo

service rsyslog restart 

Zdroj: Povolit protokolování crontab v Debianu Linux

V některých systémech (Ubuntu) není samostatný protokolovací soubor pro cron ve výchozím nastavení povolen, ale v souboru syslog se objevují protokoly související s protokolem cron. Jeden může použít

cat /var/log/syslog | grep cron

pro zobrazení zpráv souvisejících se službou cron.

    
odpověděl 6 revs, 5 users 34%unknown 11.05.2016 12:48
21

Cron volá skript, který není spustitelný.

Spuštěnímchmod +x /path/to/scrip skript se stává spustitelným a tento problém by měl vyřešit.

    
odpověděl jet 26.01.2011 19:24
16

Pokud váš cronjob vyvolá aplikace GUI, musíte jim říct, jaké DISPLAY by měly používat.

Příklad: spuštění aplikace Firefox s aplikací cron.

Váš skript by měl obsahovatexport DISPLAY=:0 somewhere.

    
odpověděl andrew 26.07.2012 17:46
14

Problémy s oprávněním jsou zcela běžné, obávám se.

Všimněte si, že běžné řešení je vykonat všechno pomocí root crontab, což je někdy opravdu špatný nápad. Nastavení správných oprávnění je určitě převážně přehlédnutým problémem.

    
odpověděl user9521 26.01.2011 16:53
13

Nebezpečné oprávnění tabulky cron

Tabulka cron je odmítnuta je-li jeho oprávnění nejisté

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)

Problém je vyřešen pomocí

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
    
odpověděl John Peterson 15.06.2013 05:12
11

Skript je citlivý na polohu. To se týká vždy používání absolutních cest v skriptu, ale ne zcela stejný. Vaše úloha cron může potřebovatcd ke konkrétnímu adresáři před spuštěním, např. může být potřeba provést úkol rake na aplikaci Rails v kořenovém adresáři aplikací Rake pro nalezení správného úkolu, nemluvě o příslušné konfiguraci databáze atd.

Takže položka crontab

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

bude lepší než

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

Nebo, aby se položka crontab jednodušší a méně křehká:

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

s následujícím kódem v/home/<user>/scripts/session-purge.sh:

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
    
odpověděl pjmorse 29.11.2011 16:20
10

Crontab specifikace , které v minulosti fungovaly , mohou být přerušeny, pokud jsou přesunuty z jednoho souboru crontab do jiného. Někdy je důvodem, že jste presunuli spec ze souboru systému crontab do souboru crontab uživatele nebo naopak.

Formát specifikace úlohy cron se liší mezi soubory crontab uživatelů (/ var / spool / cron / username nebo / var / spool / cron / crontabs / username) a systémem crontabs (/etc/crontab a soubory v% co_kde %).

Systémové crontabs mají extra pole 'user' přímo před příkazem pro spuštění.

Pokud přesunete příkaz z/etc/cron.d nebo soubor vgeorge; command not found do souboru crontab uživatele, způsobí to chyby /etc/crontab .

Naproti tomu cron přinese chyby jako /etc/cron.d nebo podobné, když dojde k obrácení.

    
odpověděl pbr 25.10.2013 17:04
9

cron skript vyvolává příkaz s volbou --verbose

Měl jsem na mně skript cron, protože jsem byl při psaní skriptu autopilot a zahrnoval volbu --verbose:

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

Během spouštění ze skriptu byl skript v pořádku, ale při spuštění z crontabu se nepodařilo, protože verbose výstup přechází na stdout při spuštění z shell, ale nikde při spuštění z crontab. Snadné vyřešení odstranění "v":

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
    
odpověděl Aaron Peart 03.06.2012 08:59
7

Nejčastějším důvodem, proč jsem viděl, že se cron nezdaří v nesprávně stanoveném rozvrhu. Vyžaduje praxi, aby byla zadána zakázka naplánovaná na 11:15 hod. Jako30 23 * * * namísto* * 11 15 * nebo11 15 * * *. Den po týdnu pro pracovní místa po půlnoci také zmatený M-F je2-6 po půlnoci ne1-5. Konkrétní data jsou obvykle problém, protože zřídkakdy je používáme* * 3 1 * není 3.března.

Pokud vaše práce s různými platformami používajícími nepodporované možnosti, jako je2/3 v časových specifikacích, může také způsobit selhání. To je velmi užitečná možnost, ale není univerzálně dostupná. Měl jsem také spouštět všechny problémy se seznamy, jako je1-5 nebo1,3,5.

Použití nekvalifikovaných cest vedlo také k problémům. Výchozí cesta je obvykle/bin:/usr/bin, takže budou spuštěny pouze standardní příkazy. Tyto adresáře obvykle nemají požadovaný příkaz. To také ovlivňuje skripty používající nestandardní příkazy. Jiné proměnné prostředí také chybí.

Chromování stávajícího crontabu mi způsobilo problémy. Nyní jsem načíst z kopie souboru. Toto může být obnoveno z existujícího crontabu pomocícrontab -l, pokud se dostane do clobbered. Chovám kopii crontabu v ~ / bin. Označuje se v celém textu a končí koncem# EOF. Toto je denně načítáno z položky crontab jako:

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

Výše ​​uvedený příkaz reload se spoléhá na spustitelný crontab s cestou bang běžící crontab. Některé systémy vyžadují spuštění příkazu crontab v příkazu a zadání souboru. Je-li adresář sdílený sítí, často používám jménocrontab.$(hostname) jako název souboru. To nakonec opraví případy, kdy je na nesprávném serveru vložen nesprávný crontab.

Použití souboru poskytuje zálohu toho, co má být crontab, a dovoluje dočasné úpravy (pouze v případě, že používámcrontab -e), aby se automaticky vybralo. K dispozici jsou záhlaví, které vám pomohou správně nastavit parametry plánování. Přidali jsme je, když by uživatelé neměl zkušenosti s úpravou crontabu.

Málokdy jsem narazil na příkazy, které vyžadují vstup uživatele. Ty se nezdaří pod crontabem, ačkoli někteří budou pracovat s přesměrováním vstupu.

    
odpověděl BillThor 01.02.2011 19:37
6

Pokud přistupujete k účtu přes klíče SSH, je možné se přihlásit k účtu, ale nevidíte, že je heslo v účtu uzamčeno (např. kvůli vypršení nebo neplatným pokusům o heslo)

Pokud systém používá PAM a účet je uzamčen, může zastavit jeho spuštění. (Testoval jsem to na Solarisu, ale ne na Ubuntu)

Ve zprávách / var / adm / messages můžete najít takové zprávy:

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

Vše, co musíte udělat, je spustit:

# passwd -u <USERNAME>

jako root pro odemčení účtu a crontab by měl fungovat znovu.

    
odpověděl JohnGH 24.10.2012 09:22
4

Pokud máte takový příkaz:

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

a nefunguje a nevidíte žádný výstup, nemusí to nutně znamenat, že cron nefunguje. Skript by mohl být přerušený a výstup bude stderr , který se nepřechází na / tmp / output. Zkontrolujte, zda tomu tak není, a to i zachycením tohoto výstupu:

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

, abyste zjistili, zda vám to pomůže zachytit váš problém.

    
odpověděl Philluminati 18.04.2018 20:26
3

=== Upozornění na docker ===

Pokud používáte docker,

Myslím, že je správné dodat, že se nepodařilo, aby se cron spustil na pozadí.

Pro spuštění úlohy cron uvnitř kontejneru jsem použil supervizora a spustilcron -f společně s dalším procesem.

Upravit: Další problém - také jsem se nepodařilo dostat to fungovat při spuštění kontejneru s HOST sítí. Tento problém naleznete také zde: Odkaz

    
odpověděl AlonL 20.05.2015 17:48
3

V mém případě cron a crontab měli jiné vlastníky.

Nepracuje to, co jsem měl:

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 

V podstatě jsem musel spustit cron-config a odpovědět na otázky správně. Tam je místo, kde jsem byl požadován pro zadání mého uživatelského hesla Win7 pro můj uživatelský účet. Od čtení jsem to vypadal, že se jedná o potenciální bezpečnostní problém, ale já jsem jediný správce v jedné domácí síti, takže jsem se rozhodl, že je to v pořádku.

Zde je sekvence příkazů, která mě dostala:

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 ~ $
    
odpověděl KiloOne 10.12.2015 10:20
3

Psal jsem instalační skript skriptů, který vytváří jiný skript pro vyčištění starých transakčních dat z databáze. Jako součást úkolu musel nakonfigurovat každodenní úlohu cron pro běh v libovolném čase, kdy byla zatížení databáze nízká.

Vytvořil jsem soubormycronjob s časovým plánem cron, uživatelským jménem & příkaz a zkopírujte jej do adresáře/etc/cron.d. Moji dva chlapci:

  1. Soubormycronjob musí vlastnit kořenový adresář
  2. Musela jsem nastavit oprávnění souboru na 644 - 664 by se neměla spustit.

Problém s oprávněním se objeví v/var/log/syslog jako něco podobného:

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)

První řádek odkazuje na soubor/etc/crontab a později na soubor, který jsem umístil pod/etc/cront.d.

    
odpověděl Izik Golan 24.04.2017 21:53
2

Řádek napsaný způsobem, kterým crontab nerozumí. Musí být správně napsáno. Zde je CrontabHowTo .

    
odpověděl Kangarooo 02.02.2011 20:52
2

Cron démon může běžet, ale ve skutečnosti nefunguje. Zkuste restartovat cron:

sudo /etc/init.d/cron restart
    
odpověděl Phil Dodd 25.11.2011 00:20
2

Psaní na cron přes "crontab -e" s argumentem uživatelského jména v řádku. Viděla jsem příklady uživatelů (nebo sysadminů), kteří píšou své shell skripty a nepochopili, proč neumí automatizovat. Argument "user" existuje v souboru / etc / crontab, nikoliv v uživatelsky definovaných souborech. takže váš osobní soubor by například vypadal takto:

# m h dom mon dow command

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

Zatímco / etc / crontab by byl:

# m h dom mon dow user   command

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

Tak proč bys to udělal? No, v závislosti na tom, jak chcete nastavit vaše oprávnění, může to být velmi spletité. Napsal jsem skripty pro automatizaci úkolů pro uživatele, kteří nerozumí složitosti, nebo se nechtějí obtěžovat s výtržností. Nastavením oprávnění na--x------ můžu skript spustit, aniž by byl schopen číst (a možná náhodně změnit). Chtěl bych však spustit tento příkaz s několika dalšími z jednoho souboru (což usnadňuje údržbu), ale ujistěte se, že výstup souboru je přiřazen správnému vlastníkovi. V takovém případě (přinejmenším v Ubuntu 10.10) se přeruší jak neschopnost číst soubor, tak i spuštění, plus výše zmíněný problém s uvedením období v souboru / etc / crontab (což, co_kde%).

Jako příklad jsem viděl příkladycrontab -e, které byly použity ke spuštění skriptu s kořenovými oprávněními, s odpovídajícímsudo crontab -e ve skriptu shellu. Sloppy, ale to funguje. IMHO, tím spíše elegantní volba je vchown username file_output s deklarovaným uživatelským jménem a správnými oprávněními, takže/etc/crontab jde na správné místo a vlastníka.

    
odpověděl Mange 12.06.2012 19:42
2

Vybuzení toho, co Aaron Peart zmínil o verbose módu, někdy skripty, které nejsou v verbose módu, se inicializují, ale nekončí, pokud je výchozí chování příkazu, který je součástí příkazu, výstup linky nebo více na obrazovku po spuštění proc. Například jsem napsal zálohovací skript pro náš intranet, který používal zvlnění, nástroj, který stahuje nebo odkládá soubory na vzdálené servery, a je velmi užitečné, pokud máte přístup pouze ke zmíněným vzdáleným souborům prostřednictvím protokolu HTTP. Použití odkazu Link způsobilo zkreslení, které jsem napsal, abych visel a nikdy nekompletoval, protože vypíná nový řádek, po němž následuje řada postupů. Musel jsem použít tichý příznak (-s), abych mu nedal žádné informace a napsal ve svém vlastním kódu, aby zvládl, zda se soubor nepodařilo stáhnout.

    
odpověděl Mange 12.06.2012 22:06
2

Ačkoli můžete definovat proměnné prostředí ve vašem souboru crontable, nejste v shell skriptu. Takže konstrukce jako následující nebudou fungovat:

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}

Důvodem je to, že proměnné nejsou interpretovány v šabloně: všechny hodnoty jsou odebírány litterálně. A to je stejné, pokud vynecháte závorky. Takže vaše příkazy se nebudou spouštět a vaše soubory protokolu nebudou zapsány ...

Místo toho musíte definovat všechny své proměnné prostředí:

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}
    
odpověděl Alexandre 07.06.2013 11:13
2

Když je úloha spuštěna v cronu, stdin je uzavřen. Programy, které se chovají odlišně na základě toho, zda je stdin k dispozici nebo nikoliv, se budou chovat jinak než v shellu a v cronu.

Příkladem je programgoaccess pro analýzu souborů protokolu webového serveru. Toto nefunguje v cronu:

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

agoaccess zobrazí stránku nápovědy namísto vytvoření sestavy. Ve schránce může být reprodukován pomocí

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

Oprava progoaccess je, aby bylo čtení protokolu ze stdin namísto čtení ze souboru, takže řešením je změnit položku crontab na

cat /var/log/nginx/access.log | goaccess -a > output.html
    
odpověděl Martijn de Milliano 09.08.2013 22:27
2

Na mých serverech RHEL7 by se spouštěly úlohy root cron, ale uživatelské úlohy by nebyly. Zjistil jsem, že bez domovského adresáře se úlohy nespustí (ale u / var / log / cron se objeví dobré chyby). Když jsem vytvořil domovský adresář, problém byl vyřešen.

    
odpověděl Dennis Parslow 02.02.2017 22:29
2

Pokud jste upravili soubor crontab pomocí editoru systému Windows (pomocí programu samba nebo něco podobného) a nahrazují nové řádky \ n \ r nebo jen \ r, cron nebude spuštěn.

Pokud používáte také /etc/cron.d/* a jeden z těchto souborů má \ r v něm, cron se přesune soubory a zastaví se, když narazí na špatný soubor. Nejste si jisti, jestli je to problém?

Použijte:

od -c /etc/cron.d/* | grep \r
    
odpověděl Doug 20.04.2017 03:38