it-swarm.dev

Proč skripty crontab nefungují?

Skripty crontab se často neprovedou podle plánu nebo podle očekávání. Existuje mnoho důvodů:

  1. špatný zápis crontabu
  2. problém s oprávněními
  3. proměnné prostředí

Cílem této wiki komunity je agregovat hlavní důvody, proč se skripty crontab neprovedou podle očekávání. Každý důvod napište do samostatné odpovědi.

Uveďte prosím jeden důvod pro odpověď - podrobnosti o tom, proč nebyla provedena - a oprava z tohoto důvodu.

Napište pouze problémy specifické pro cron, např. příkazy, které se provádějí podle očekávání od shellu, ale provádějí chybně pomocí cronu.

562
Adam Matan

Různé prostředí

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

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

Čekat na /tmp/env.output k vytvoření a poté úlohu znovu odeberte. Nyní porovnejte obsah /tmp/env.output s výstupem env běží ve vašem běžném terminálu.

Běžnou „gotcha“ je proměnná prostředí PATH, která se liší. Možná váš skript cron používá příkaz somecommand nalezený v /opt/someApp/bin, které jste přidali do PATH v /etc/environment? cron ignoruje PATH z tohoto souboru, takže běh somecommand z vašeho skriptu selže při spuštění s cronem, ale pracuje, když je spuštěn v terminálu. Je třeba poznamenat, že proměnné z /etc/environment bude předáno úlohám cron, ale ne proměnné cron se specificky nastaví samy, například PATH.

Chcete-li to obejít, stačí nastavit vlastní proměnnou PATH 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 místo toho používají absolutní cesty ke všem příkazům. Doporučuji proti tomu. Zvažte, co se stane, pokud chcete spustit skript v jiném systému a v tomto systému je příkaz v /opt/someAppv2.2/bin namísto. Museli byste projít celý skript a nahradit /opt/someApp/bin s /opt/someAppv2.2/bin namísto jen malé úpravy na prvním řádku skriptu.

Můžete také nastavit proměnnou PATH v souboru crontab, který bude platit pro 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
529
geirha

Moje nejlepší gotcha: Pokud zapomenete přidat nový řádek na konec souboru crontab. Jinými slovy, soubor crontab by měl končit prázdným řádkem.

Níže je relevantní část na manuálových stránkách pro tento problém (man crontab 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)
347
user4124

Cron démon není spuštěn. Opravdu jsem s tím přišel před několika měsíci.

Typ:

pgrep cron 

Pokud nevidíte žádné číslo, cron neběží. Sudo /etc/init.d/cron start lze použít ke spuštění cronu.

EDIT: Spíše než vyvolání inicializačních skriptů pomocí /etc/init.d, použijte obslužný program, např.

Sudo service cron start

EDIT: Také byste mohli použít systemctl v moderním Linuxu, např.

Sudo systemctl start cron
144
aneeshep

Názvy skriptů v cron.d/, cron.daily/, cron.hourly/ atd. by nemělo obsahovat tečku (.), jinak je přeskočí části.

Viz 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_-]+$).

Pokud tedy máte skript cron backup.sh, analyze-logs.pl v cron.daily/ adresář, měli byste odstranit názvy přípon.

95
Xiè Jìléi

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

Návrhy na otestování nebo opravu neúspěšného příkazu:

  • Zkuste spustit příkaz v sh, abyste zjistili, zda funguje:

    sh -c "mycommand"
    
  • Zabalte příkaz do bash subshell, abyste se ujistili, že bude spuštěn v bash:

    bash -c "mybashcommand"
    
  • Řekněte cronovi, aby spustil všechny příkazy v bashu nastavením Shell na horní část vašeho crontabu:

    Shell=/bin/bash
    
  • Pokud je příkazem skript, ujistěte se, že skript obsahuje Shebang:

    #!/bin/bash
    
72
Ian Mackinnon

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

Sudo service cron restart
41
luissquall

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

Například namísto grep by měl být použit /bin/grep:

# 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

To je obzvláště ošidné, protože stejný příkaz bude fungovat, když bude spuštěn z prostředí Shell. Důvod je ten, že cron nemá stejnou proměnnou prostředí PATH jako uživatel.

36
Adam Matan

Pokud váš příkaz crontab obsahuje symbol %, Cron se ho pokusí interpretovat. Takže pokud jste používali jakýkoli příkaz s % V něm (například specifikace formátu k příkazu date), budete jej muset uniknout.

To a další dobré gotchas zde:
http://www.pantz.org/software/cron/croninfo.html

34
JMS

Cron volá skript, který nelze spustit.

Spuštěním chmod +x /path/to/script, skript se stane spustitelným a to by mělo tento problém vyřešit.

26
jet

Je také možné, že platnost hesla uživatele vypršela. Platnost hesla může vypršet i rootovi. Můžeš tail -f /var/log/cron.log a uvidíte cron selhání s vypršením hesla. Heslo můžete nastavit tak, aby nikdy nevypršelo: passwd -x -1 <username>

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

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

by měla být upravena (Sudo nano /etc/rsyslog.conf) bez doporučení:

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í crontabu v Debian Linux

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

cat /var/log/syslog | grep cron -i

pro zobrazení zpráv souvisejících s cronem.

25
Daniel Tet

Pokud vaše cronjob vyvolá GUI-aplikace, musíte jim sdělit, co DISPLAY mají používat.

Příklad: Spuštění Firefoxu s cronem.

Váš skript by měl obsahovat export DISPLAY=:0 někde.

18
andrew

Obávám se, že problémy s povolením jsou docela běžné.

Všimněte si, že běžným řešením je provést vše pomocí kořenového crontabu, což je někdy opravdu špatný nápad. Nastavení správných oprávnění je rozhodně velmi přehlíženým problémem.

15
user9521

Neplatné povolení tabulky cronů

Tabulka cronů je odmítnuta , pokud je její oprávnění nezabezpečené

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

# correct permission
Sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
Sudo touch /var/spool/cron/crontabs
14
John Peterson

Skript je citlivý na umístění. S tím souvisí vždy používání absolutních cest ve skriptu, ale ne úplně stejné. Před spuštěním vaší úlohy cron bude možná třeba cd do konkrétního adresáře, např. úloha rake v aplikaci Rails) může být v kořenové aplikaci potřeba, aby Rake našel správnou úlohu, nemluvě o vhodné konfiguraci databáze atd.

Takže vstup do crontabu

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

by bylo lepší jako

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

Nebo, aby byl vstup 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 
13
pjmorse

Specifikace crontabu , které fungovaly v minulosti , se mohou zlomit při přesunu z jednoho souboru crontab do druhého. Důvodem je někdy to, že jste přesunuli spec ze souboru crontab systému 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 crontabs systému (/etc/crontab a soubory v /etc/cron.d).

Systémové crontaby mají pole „user“ ještě před příkazem ke spuštění.

To způsobí chyby uvádějící například george; command not found když přesunete příkaz z /etc/crontab nebo soubor v /etc/cron.d do souboru crontab uživatele.

Naopak, cron zobrazí chyby jako /usr/bin/restartxyz is not a valid username nebo podobné, když dojde k obrácení.

11
pbr

Nejčastějším důvodem, proč jsem viděl selhání cronů v nesprávně stanoveném rozvrhu. Prakticky je třeba zadat úlohu naplánovanou na 23:15 jako 15 23 * * * Místo * * 11 15 * Nebo 11 15 * * *. Den v týdnu pro pracovní místa po půlnoci také zmatený M-F je 2-6 Po půlnoci, nikoli 1-5. Specifická data jsou obvykle problémem, protože je používáme jen zřídka. * * 3 1 * Není 3. března. Pokud si nejste jisti, zkontrolujte své cron plány online na https://crontab.guru/ .

Pokud vaše práce s různými platformami, které používají nepodporované možnosti, jako je 2/3, Může způsobit chyby. Toto je velmi užitečná možnost, ale není všeobecně dostupná. Také jsem narazil na problémy se seznamy, jako jsou 1-5 Nebo 1,3,5.

Problémy způsobily také použití nekvalifikovaných cest. 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. Mohou také chybět další proměnné prostředí.

Kolébání existujícího crontabu mi úplně způsobilo problémy. Nyní načtu ze kopie souboru. Toto může být obnoveno z existujícího crontabu pomocí crontab -l, Pokud se dostane clobbered. Kopii crontab uchovávám v ~/bin. Je komentován v celém textu a končí řádkem # EOF. Toto je znovu načteno ze záznamu crontab jako:

#!/usr/bin/crontab 
 # Znovu načíst tento crontab 
 # 
 54 12 * * * $ {HOME}/bin/crontab

Příkaz reload výše se spoléhá na spustitelný crontab, u kterého je crontab spuštěna třesk. Některé systémy vyžadují běžící crontab v příkazu a určující soubor. Pokud je adresář sdílen v síti, často používám jako název souboru crontab.$(hostname). To nakonec napraví případy, kdy je na nesprávný server načten nesprávný crontab.

Použití souboru poskytuje zálohu toho, co by crontab mělo být, a umožňuje automatické zálohování dočasných úprav (jediný čas, kdy používám crontab -e). K dispozici jsou záhlaví, která pomáhají při správném nastavení parametrů plánování. Přidal jsem je, když nezkušení uživatelé upravují crontab.

Zřídka jsem narazil na příkazy, které vyžadují vstup uživatele. Tito selhávají pod crontab, ačkoli někteří budou pracovat s přesměrováním vstupu.

10
BillThor

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

Měl jsem selhání cron skriptu, protože jsem byl v autopilotu při psaní skriptu a zahrnul jsem volbu --verbose:

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

Skript běžel dobře při spuštění ze Shell, ale selhal při spuštění z crontab, protože podrobný výstup jde do stdout při spuštění z Shell, ale nikde při spuštění z crontab. Snadná oprava pro odstranění 'v':

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
10
Aaron Peart

Pokud máte takový příkaz:

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

a nefunguje to a nevidíte žádný výstup, nemusí to nutně znamenat, že cron nefunguje. Skript může být rozbit a výstup bude stderr, který nebude předán do/tmp/output. Zkontrolujte, zda tomu tak není, a to také zachycením tohoto výstupu:

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

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

9
Philluminati

Pokud přistupujete k účtu pomocí SSH klíčů, je možné se přihlásit k účtu, ale nevšimnete si, že heslo na účtu je zamčené (např. Kvůli vypršení platnosti nebo neplatným pokusům o heslo)

Pokud systém používá PAM a účet je zamčený, může to zastavit jeho cronjob. (Testoval jsem to na Solarisu, ale ne na Ubuntu)

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

 24. října 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron se pokouší o ověření uzamčeného účtu z lokálního hostitele 
 24. října 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron se pokouší o ověření uzamknutého účtu myuser z místního hostitele 
 24. října 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account : cron se pokouší o ověření uzivatele uzamknutého účtu z místního hostitele 
 24. října 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron se pokouší o ověření uzamknutého účtu uzivatele z místního hostitele 

Vše, co byste měli udělat, je spustit:

 # passwd -u <USERNAME> 

jako root k odemknutí účtu a crontab by měl znovu fungovat.

7
JohnGH

Napsal jsem instalační skript Shell, který vytváří další skript pro vymazání starých transakčních dat z databáze. V rámci úkolu musela každý den nakonfigurovat cron úlohu, která se spouští v libovolném čase, kdy je zatížení databáze nízké.

Vytvořil jsem soubor mycronjob s plánem cron, uživatelským jménem a příkazem a zkopíroval jsem ho do /etc/cron.d adresář. Moje dva gotchas:

  1. Aby mohl být soubor mycronjob vlastněn, musí být root
  2. Musel jsem nastavit oprávnění k souboru, aby 644 - 664 nemohl běžet.

Problém oprávnění 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 /etc/crontab a později do souboru, který jsem umístil pod /etc/cront.d.

3
allaptr

=== Upozornění Docker ===

Pokud používáte ukotvitelný panel,

Myslím, že je správné dodat, že se mi nepodařilo přimět crona, aby běžel na pozadí.

Ke spuštění úlohy cron uvnitř kontejneru jsem použil supervizora a spustil cron -f, spolu s dalším procesem.

Úpravy: Další problém - při spuštění kontejneru s hostitelskou sítí se mi také nepodařilo zajistit jeho fungování. Podívejte se také na tento problém: https://github.com/phusion/baseimage-docker/issues/144

3
AlonL

Démon Cron mohl běžet, ale ve skutečnosti nefungoval. Zkuste restartovat cron:

Sudo /etc/init.d/cron restart
2
Phil Dodd

Ačkoli můžete definovat proměnné prostředí ve vašem crontable, nejste ve skriptu Shell. Tak 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, že proměnné nejsou interpretovány v crontable: všechny hodnoty jsou vzaty doslovně. A toto je stejné, pokud vynecháte závorky. Takže vaše příkazy nebudou spuštěny a vaše logovací soubory nebudou zapsány ...

Místo toho musíte rovnou definovat všechny 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}
2
Alexandre

Na základě toho, co Aaron Peart zmínil o podrobném režimu, se někdy skripty, které nejsou v podrobném režimu, inicializují, ale nedokončí, pokud je výchozím chováním zahrnutého příkazu výstup řádku nebo více na obrazovku, jakmile se spustí proc. Napsal jsem například záložní skript pro náš intranet, který používal curl, což je nástroj, který stahuje nebo odesílá soubory na vzdálené servery, a je docela užitečné, pokud k uvedeným vzdáleným souborům můžete přistupovat pouze prostřednictvím HTTP. Použití 'curl http://something.com/somefile.xls ' způsobilo skript, který jsem napsal, aby se zastavil a nikdy nedokončil, protože vyplivuje nový řádek následovaný linií pokroku. Musel jsem použít tichý příznak (-s), abych mu řekl, aby nevytvářel žádné informace, a zapisuj svůj vlastní kód, abych zvládl, jestli se soubor nepodaří stáhnout.

2
Mange

V 16.04, pokud máte tuto chybu v syslogu

(CRON) error (can't fork)

snaž se:

systemctl status cron.service

Ve výsledku:

Tasks: num_task (limit: 512)

Pokud num_task je blízko limitu použití:

systemctl set-property cron.service TasksMax=new_max

Nahradit new_max s vhodnou hodnotou.

Linka psaná způsobem crontab nerozumí. Musí být správně napsáno. Zde je CrontabHowTo .

2
Kangarooo

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

2
Dennis Parslow

Zápis do cronu přes "crontab -e" s argumentem username v řádku. Viděl jsem příklady uživatelů (nebo sysadminů), kteří psali své skripty Shell a nechápali, proč se automatizují. Argument „user“ existuje v/etc/crontab, ale ne v uživatelsky definovaných souborech. takže například váš osobní soubor by byl něco jako:

# m h dom mon dow command

* * */2  *   *  /some/Shell/script

zatímco/etc/crontab by bylo:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/Shell/script

Tak proč bys to udělal? V závislosti na tom, jak chcete nastavit svá oprávnění, to může být velmi spletité. Napsal jsem skripty pro automatizaci úkolů pro uživatele, kteří nerozumí složitosti nebo se nechtějí obtěžovat drulgery. Nastavením oprávnění na --x------ Mohu učinit skript spustitelným, aniž by je mohl číst (a možná náhodně změnit). Mohl bych však chtít 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. Pokud tak učiníte (přinejmenším v Ubuntu 10.10), dojde k přerušení jak čtení, tak i spuštění souboru, plus výše zmíněného problému s vkládáním období do/etc/crontab (což je celkem zábavné, při procházení crontab -e).

Jako příklad jsem viděl instance Sudo crontab -e Používané ke spuštění skriptu s oprávněními root, s odpovídajícím chown username file_output Ve skriptu Shell. Sloppy, ale funguje to. IMHO, Elegantnější možností je vložit ji do /etc/crontab S deklarovaným uživatelským jménem a příslušnými oprávněními, takže file_output Jde na správné místo a majitele.

2
Mange

Když je úkol spuštěn v rámci cron, stdin je uzavřen. Programy, které se chovají odlišně na základě toho, zda je stdin k dispozici nebo ne, se budou chovat odlišně mezi relací Shell a v cronu.

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

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

a goaccess zobrazuje stránku nápovědy místo vytváření sestavy. V Shell to lze reprodukovat

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

Oprava goaccess spočívá v tom, že umožňuje č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
2

Úlohy Cron se nespustí, pokud vyprší platnost hesla uživatele.

Jedním z náznaků je to, pokud váš cron log (obvykle /var/log/syslog na Ubuntu, věřím) obsahuje zprávy jako „Ověřovací token již není platný; je vyžadován nový“.

Tento problém můžete zkontrolovat spuštěním Sudo chage -l the_username.

Zde je příklad hesla, jehož platnost vypršela:

$ Sudo chage -l root
Last password change                    : password must be changed
Password expires                    : password must be changed
Password inactive                   : password must be changed
Account expires                     : never
Minimum number of days between password change      : 0
Maximum number of days between password change      : 14600
Number of days of warning before password expires   : 14

Oprava je změna hesla. Například:

Sudo -u root passwd

Poté postupujte podle pokynů a podle pokynů zadejte nové heslo.

Díky https://serverfault.com/questions/449651/why-is-my-crontab-not-working-and-how-can-i-troubleshoot-it#comment966708_544905 za nasměrování správným směrem zde. V mém případě, stejně jako u tohoto komentátora, to byl kořenový uživatel schránky DigitalOcean.

2
Henrik N

V mém případě měl cron a crontab různé majitele.

NEPracoval jsem to měl:

[email protected] ~ $ 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ě. Je bod, kdy jsem byl povinen zadat své uživatelské heslo pro Win7 pro svůj uživatelský účet. Od přečtení jsem to vypadal, že se jedná o potenciální bezpečnostní problém, ale já jsem jediný administrátor v jedné domácí síti, takže jsem se rozhodl, že je v pořádku.

Zde je příkazová sekvence, která mě donutila jít:

[email protected] ~ $ 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 [email protected]
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.


[email protected] ~ $ 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

[email protected] ~ $
2
KiloOne

Pokud jste upravili svůj crontab soubor pomocí editoru Windows (přes sambu nebo tak něco) a nahradili jste nové řádky\n\r nebo jen\r, cron se nespustí.

Také pokud používáte /etc/cron.d/* a jeden z těchto souborů obsahuje\rc, cron se bude pohybovat mezi soubory a zastaví se, když zasáhne špatný soubor. Nejste si jisti, zda je to problém?

Použití:

od -c /etc/cron.d/* | grep \r
2
Doug

Výchozí soubory .bashrc na UBuntu 16.04 (a mnoho dalších verzí) mají vestavěný mechanismus, který nic nedělá pokud nejde o interaktivní prostředí Shell.

To může zabránit tomu, aby byl soubor správně získán uvnitř skriptu, který spouští cron! Chcete-li tomu zabránit, přidejte v horní části souboru .bashrc následující řádky:

Ubuntu 16.04

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Ubuntu 12.04 a některé další verze

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Dokud tyto crony zůstanou, pokud cron spustí skript, ze kterého pochází váš .bashrc soubor, nedostanete ve skutečnosti žádné proměnné prostředí, na které jste zvyklí uvnitř vašeho terminálu!

2
GrayedFox

Další Gotcha:

Když zadáte crontab -e A uložíte jej do editoru, nebude to mít žádný účinek. Musíte editor opustit, abyste jej mohli přidat nebo aktualizovat podle vašich změn (např. Použijte :x Ve Vimu).

(crontab -e Efektivně spouští "editovat cron soubor; aktualizace ze cron souboru", takže blokuje editor, dokud jej nezavřete.)

1
mahemoff

Měl jsem problém se skriptem, který volal grep s regulárním výrazem. Některé regexy fungovaly, když byl skript volán z crontabu, zatímco jiné ne, např. [[: print:]] nefungoval. Ukazuje se, že proměnná prostředí LANG má vliv na znakové sady jako [a-z] nebo [[: print:]]. Když jsem vložil svou proměnnou prostředí LANG do horní části mého crontabu, tj. „LANG = en_GB.UTF-8“, grep regulární výrazy fungovaly dobře, když byl skript vyvolán z crontabu. HTH.

1
user166286

Oprávnění k protokolování

Velmi jednoduchý crontab, nebude proveden, protože /var/log/ nelze zapisovat pomocí účtu luser!

* * * * * /usr/local/bin/teamviewer_check >> /var/log/teamviewer.log 2>&1

ŘEŠENÍ: vytvořte soubor jako root a chmod to 777

Díky předchozímu návrhu povolit přihlášení cronů /etc/rsyslog.d/50-default.conf, vede k záznamu syslog (No MTA installed, discarding output), pak díky "(CRON) info (není nainstalován MTA, zahozen výstup)" chyba v syslog instalace postfixu v lokálním režimu, tail/var/mail/luser, /bin/sh: 1: cannot create /var/log/teamviewer.log: Permission denied

1
kevinf

Další upozornění:

Pokuste se nevkládat vaše cron skripty do domovského adresáře uživatele.

Právě jsem měl problém, kde se všechno zdálo dobře, ale hned po chvíli - pravděpodobně za pár hodin po odhlášení se přestanou fungovat úlohy cronu a tyto zprávy se objeví v protokolu:

Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'

Můj domovský adresář, alespoň pokud vím, není šifrován. Problém však vyřešil přesun těchto skriptů mimo domov.

1
AlonL

Můj crontab fungoval, pouze když jsem byl přihlášen jako uživatel.

Našel jsem řešení navržené zde na Unix & Linux SE

Problém byl v tom, že skripty byly v mém domovském adresáři, který byl šifrován. Když jsem byl přihlášen, bude to odpojeno a nedostupné. Pomocí příkazu mount můžete zjistit, zda je váš domovský adresář připojen k šifrování.

Opravil jsem problém vložením svých skriptů do /usr/local/bin složka.

1
Paul

Po hodinách zjistil problém, kde jsem editoval skript Shell z Windows ( notepad ++ ), kde byl soubor původně umístěn v server Linux a nový znak řádku jsem vynechal.

Protože jsem editoval soubor pomocí Notepad ++ , musel jsem udělat EOL konverze na Unix za účelem získání nového znaku řádku a fungovalo to perfektně.

Doufám, že to pomůže!

1
Kulasangar

Pokud crontab zmiňuje něco jako run-parts /etc/cron.daily, pak run-parts může odmítnout spuštění skriptu. V mém případě skript v cron.daily nezačal #!/Bin/sh.

Objevil jsem to vložením skriptu do adresáře sám a spuštěním run-parts proti tomuto adresáři.

1
Michael Mather

To se mi nedávno stalo: měl jsem dva řádky, které modifikovaly PATH, takto:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/ernesto/bin

Poté, později v souboru:

PATH=$PATH:/some/other/path

jako obvykle v kontextu interpretovaném Shell. Zdá se však, že $ PATH nebyla rozšířena, což způsobí selhání všech mých úloh. Řešením je dát vše na jeden řádek.

Upravit:

Protože jsem nechtěl čekat na další normální iteraci anacronu, abych si ověřil, že moje práce fungují správně, běžel jsem:

anacron -fnd "jobname"

Kde "jobname" je identifikátor úlohy uvedený v anacrontab. To nutí úlohy, aby byly spouštěny stejným procesem anacronu, postupně a bez prodlení.

1
erjoalgo

Použili jste:

*  *  * * * DISPLAY=:0 /path/to/your/app

ale selhalo, protože vaše ~/.dbus adresář nevlastníte vy, ale root. Zkontroluj to:

ls -l ~/.dbus
0
loxaxs

Jednou jsem pracoval na sdíleném serveru s množstvím omezení .

Všechny odpovědi zde (PATH, Shell, bash -c, ...) nemohly dostat můj skript pro práci v crontabu.

Fungovalo to perfektně, když jsem dal příkaz do malého skriptového soubor s PATH, Shell a Shebang, spíše než do samotného crontabu. Oprávnění jsem musel změnit na 700.

0
don.joey

Někdy cron funguje dobře, ale skript nebo příkaz, který chcete spustit, selže tiše a způsobí tak štěkání nesprávného stromu.

V takových případech považuji za užitečné zalamovat cíl do jiného krátkého skriptu, který vydává viditelný ladicí kód (včetně výstupu date) a pomocí přesměrování zajistím, abych získal nějaké důkazy ke kontrole. Pokud je cílem skript, omotá se kolem sh -x může dále pomoci.

Záznam crontab (vždy upravovat pomocí crontab -e) může vypadat takto:

00 14 * * * (sh -x /tmp/my_wrapper_script) >> /tmp/debug.log 2>&1

Zkontrolovat /tmp/debug.log a jeho časové razítko. Pokud je prázdný, neexistující nebo časová značka není krátce po 14:00 (v tomto příkladu), možná máte problém s cronem, jinak musíte ladit skutečnou cílovou akci a cron funguje dobře!

0
sxc731

Měl jsem nějaké problémy s používáním Sudo v cronu.

V podstatě jsem chtěl spustit příkaz jako konkrétní uživatel a nejprve jsem otestoval příkazový řádek su, který vrátil chybu This account is not available. Pomocí Sudo byl příkaz spuštěn bez chyb.

Při spuštění z cron však příkaz Sudo vrátil následující chybu: Sudo: sorry, you must have a tty to run Sudo.

Později jsem zjistil, že použití runuser a zadání Shell pro příkaz, který se má spustit, funguje.

0
marius-nyxpoint

Pokud spouštíte skripty v rámci /etc/cron.* adresáře, ujistěte se, že vaše skripty:

  • jsou spustitelné,
  • shodovat se jmenným prostorem cron skriptu Ubuntu/Debian (^[a-zA-Z0-9_-]+$).

Například pokud máte skript s příponou (například .sh) nebude fungovat.

Chcete-li vytisknout názvy skriptů, které by se spouštěly každou hodinu, zkuste:

Sudo run-parts --report --test /etc/cron.hourly
0
kenorb