Como corrigir todos os seus problemas / problemas relacionados ao crontab (Linux)

Este é um wiki da comunidade , se você notar algo incorreto com esta resposta ou tiver informações adicionais, edite-o.

Primeiro, terminologia básica:

• cron(8) é o daemon que executa comandos agendados.
• crontab(1) é o programa usado para modificar os arquivos crontab(5) do usuário.
• crontab(5) é um arquivo por usuário que contém instruções para cron(8).

Em seguida, educação sobre o cron:

Cada usuário em um sistema pode ter seu próprio arquivo crontab. A localização dos arquivos crontab root e do usuário dependem do sistema, mas geralmente estão abaixo /var/spool/cronde .

Existe um /etc/crontabarquivo de todo o sistema, o /etc/cron.ddiretório pode conter fragmentos crontab que também são lidos e acionados pelo cron. Algumas distribuições Linux (por exemplo, Red Hat) também possuem /etc/cron.{hourly,daily,weekly,monthly}diretórios, scripts dentro dos quais serão executados a cada hora/dia/semana/mês, com privilégio de root.

root sempre pode usar o comando crontab; usuários regulares podem ou não ter acesso. Quando você edita o arquivo crontab com o comando crontab -ee o salva, o crond verifica sua validade básica, mas não garante que seu arquivo crontab esteja formado corretamente. Existe um arquivo chamado cron.denyque especificará quais usuários não podem usar o cron. A cron.denylocalização do arquivo depende do sistema e pode ser excluída, o que permitirá que todos os usuários usem o cron.

Se o computador não estiver ligado ou o daemon crond não estiver em execução, e a data/hora para a execução de um comando tiver passado, o crond não recuperará e executará consultas anteriores.

detalhes do crontab, como formular um comando:

Um comando crontab é representado por uma única linha. Você não pode usar \para estender um comando por várias linhas. O sinal de hash ( #) representa um comentário que significa que qualquer coisa nessa linha é ignorada pelo cron. Espaços em branco à esquerda e linhas em branco são ignorados.

%Tenha MUITO cuidado ao usar o sinal de porcentagem ( ) em seu comando. A menos que eles sejam escapados \%, eles são convertidos em novas linhas e tudo após o primeiro não escapado %é passado para o seu comando em stdin.

Existem dois formatos para arquivos crontab:

• Crontabs do usuário

   # 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
  

• Todo o sistema /etc/crontabe /etc/cron.dfragmentos

   # 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
  

Observe que o último requer um nome de usuário. O comando será executado como o usuário nomeado.

Os primeiros 5 campos da linha representam a(s) hora(s) em que o comando deve ser executado. Você pode usar números ou, quando aplicável, nomes de dia/mês na especificação de hora.

• Os campos são separados por espaços ou tabulações.
• Uma vírgula ( ,) é usada para especificar uma lista, por exemplo, 1,4,6,8, o que significa executar em 1,4,6,8.
• Os intervalos são especificados com um traço ( -) e podem ser combinados com listas, por exemplo, 1-3,9-12, o que significa entre 1 e 3 e depois entre 9 e 12.
• O /caractere pode ser usado para introduzir um passo, por exemplo, 2/5, o que significa começar em 2 e depois a cada 5 (2,7,12,17,22...). Eles não enrolam além do final.
• Um asterisco ( *) em um campo significa todo o intervalo para esse campo (por exemplo, 0-59para o campo minuto).
• Faixas e etapas podem ser combinadas, por exemplo */2, significa começar no mínimo para o campo relevante, depois a cada 2, por exemplo, 0 para minutos (0,2...58), 1 para meses (1,3 ... 11) etc.

Depurando comandos cron

Checar o e-mail!

Por padrão, o cron enviará qualquer saída do comando para o usuário em que está executando o comando. Se não houver saída, não haverá correio. Se você deseja que o cron envie e-mails para uma conta diferente, você pode definir a variável de ambiente MAILTO no arquivo crontab, por exemplo

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

Capture a saída você mesmo

Você pode redirecionar stdout e stderr para um arquivo. A sintaxe exata para capturar a saída pode variar dependendo de qual shell cron está usando. Aqui estão dois exemplos que salvam toda a saída em um arquivo em /tmp/mycommand.log:

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

Veja os registros

O Cron registra suas ações via syslog, que (dependendo da sua configuração) geralmente vai para /var/log/cronou /var/log/syslog.

Se necessário, você pode filtrar as instruções cron com, por exemplo,

grep CRON /var/log/syslog 

Agora que vimos o básico do cron, onde estão os arquivos e como usá-los, vamos ver alguns problemas comuns.

Verifique se o cron está em execução

Se o cron não estiver em execução, seus comandos não serão agendados ...

ps -ef | grep cron | grep -v grep

deve te dar algo como

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

ou

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

Se não reinicie

/sbin/service cron start

ou

/sbin/service crond start

Pode haver outros métodos; use o que sua distro fornece.

cron executa seu comando em um ambiente restrito.

Quais variáveis ​​de ambiente estão disponíveis provavelmente serão muito limitadas. Normalmente, você obterá apenas algumas variáveis ​​definidas, como $LOGNAME, $HOMEe $PATH.

De particular interesse é que o PATHé restrito a /bin:/usr/bin. A grande maioria dos problemas "meu script cron não funciona" são causados ​​por esse caminho restritivo . Se o seu comando estiver em um local diferente, você pode resolver isso de duas maneiras:

1. Forneça o caminho completo para seu comando.

    1 2 * * * /path/to/your/command
   

2. Forneça um PATH adequado no arquivo crontab

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

Se o seu comando requer outras variáveis ​​de ambiente, você também pode defini-las no arquivo crontab.

cron executa seu comando com cwd == $HOME

Independentemente de onde o programa que você executa resida no sistema de arquivos, o diretório de trabalho atual do programa quando o cron for executado será o diretório inicial do usuário . Se você acessar arquivos em seu programa, precisará levar isso em consideração se usar caminhos relativos ou (de preferência) apenas usar caminhos totalmente qualificados em todos os lugares e evitar muita confusão para todos.

O último comando no meu crontab não é executado

O Cron geralmente requer que os comandos sejam finalizados com uma nova linha. Edite seu crontab; vá para o final da linha que contém o último comando e insira uma nova linha (pressione enter).

Verifique o formato crontab

Você não pode usar um crontab formatado pelo usuário para /etc/crontab ou os fragmentos em /etc/cron.de vice-versa. Um crontab formatado pelo usuário não inclui um nome de usuário na 6ª posição de uma linha, enquanto um crontab formatado pelo sistema inclui o nome de usuário e executa o comando como esse usuário.

Eu coloco um arquivo em /etc/cron.{hourly,diariamente,weekly,monthly} e ele não roda

• Verifique se o nome do arquivo não tem uma extensão veja run-parts
• Certifique-se de que o arquivo tenha permissões de execução.
• Diga ao sistema o que usar ao executar seu script (por exemplo, colocar #!/bin/shno topo)

Bugs relacionados à data cron

Se sua data foi alterada recentemente por um usuário ou atualização do sistema, fuso horário ou outro, o crontab começará a se comportar de forma irregular e exibirá bugs bizarros, às vezes funcionando, às vezes não. Esta é a tentativa do crontab de tentar "fazer o que você quer" quando o tempo muda por baixo dele. O campo "minuto" se tornará ineficaz depois que a hora for alterada. Nesse cenário, apenas asteriscos seriam aceitos. Reinicie o cron e tente novamente sem se conectar à internet (para que a data não tenha a chance de ser redefinida para um dos servidores de horário).

Sinais de porcentagem, novamente

Para enfatizar o conselho sobre os sinais de porcentagem, aqui está um exemplo do que o cron faz com eles:

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

irá criar o arquivo ~/cron.out contendo as 3 linhas

foo
bar
baz

Isso é particularmente intrusivo ao usar o datecomando. Certifique-se de escapar dos sinais de porcentagem

* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")"

Como usar sudoem cron jobs

ao executar como um usuário não root,

crontab -e

irá abrir o crontab do usuário, enquanto

sudo crontab -e

irá abrir o crontab do usuário root. Não é recomendado executar comandos sudo em um cron job, portanto, se você estiver tentando executar um comando sudo no cron de um usuário, tente mover esse comando para o cron do root e remova o sudo do comando.

Debian Linux e seus derivados (Ubuntu, Mint, etc) possuem algumas peculiaridades que podem impedir que seus cron jobs sejam executados; em particular, os arquivos em /etc/cron.d, /etc/cron.{hourly,daily,weekly,monthly}devem:

• ser propriedade da raiz
• só ser gravável por root
• não pode ser gravável por grupo ou outros usuários
• tem um nome sem pontos '.' ou qualquer outro caractere especial, exceto '-' e '_' .

O último fere regularmente usuários desavisados; em particular, qualquer script em uma dessas pastas chamada whatever.sh, mycron.py, testfile.pl, etc. não será executado, nunca.

Na minha experiência, este ponto em particular tem sido de longe o motivo mais frequente para um cronjob não executável no Debian e derivados.

Veja man cronmais detalhes, se necessário.

Se seus cronjobs pararem de funcionar, verifique se sua senha não expirou.
Haverá mensagens /var/log/messagessemelhantes a esta abaixo que mostram problemas com a autenticação do usuário:

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

Horários incomuns e irregulares

O Cron é considerado um agendador muito básico e a sintaxe não permite facilmente que um administrador formule agendas um pouco mais incomuns.

Considere o seguinte trabalho que normalmente seria explicado como "executar a commandcada 5 minutos" :

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

contra:

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

que nem sempre é executado a commandcada 7 minutos .

Lembre-se que o /caractere pode ser usado para introduzir um passo, mas que os passos não vão além do final de uma série, por exemplo, */7que corresponde a cada 7 minutos a partir dos minutos 0-59 , ou seja, 0,7,14,21,28,35,42,49, 56 mas entre uma hora e outra haverá apenas 4 minutos entre os lotes , depois que 00:56uma nova série começar em 01:00, 01:07etc. (e os lotes não serão executados em 01:03, 01:10, 01:17etc.).

O que fazer em vez disso?

Crie vários lotes

Em vez de um único trabalho cron, crie vários lotes que combinados resultem no agendamento desejado.

Por exemplo, para executar um lote a cada 40 minutos (00:00, 00:40, 01:20, 02:00 etc.), crie dois lotes, um que seja executado duas vezes nas horas pares e outro que execute apenas nas horas ímpares:

# 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.

Run your batches less frequently

Rather than running your batch every 7 minutes, which is a difficult schedule to break down in multiple batches, simply run it every 10 minutes instead.

Start your batches more frequently (but prevent multiple batches from running concurrently)

Many odd schedules evolve because the batch runtimes increase/fluctuate and then the batches get scheduled with a bit of additional safety margin to prevent subsequent runs of the same batch from overlapping and running concurrently.

Instead, think differently and create a cronjob that will fail gracefully when a previous run has not finished yet, but which will run otherwise. See this Q&A:

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

That will almost immediately start a new run once the previous run of /usr/local/bin/frequent_cron_job has completed.

Start your batches more frequently (but exit gracefully when the conditions are not right)

Since cron syntax is limited you may decide to place more complex conditions and logic in the batch job itself (or in a wrapper script around the existing batch job). That allows you to utilize the advanced capabilities of your favorite scripting languages, to comment your code and will prevent hard-to-read constructs in the crontab entry itself.

In bash the seven-minute-job would then look something like something like:

#!/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

Which you can then safely (attempt) to run every minute:

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

A different, but similar problem would to schedule a batch to run on the first Monday of every month (or the second Wednesday) etc. Simply schedule the batch to run every Monday and exit when date is neither between the 1^st or 7^th and the day of the week is not Monday.

#!/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

Which you can then safely (attempt) to run every Monday:

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

Don't use cron

If your needs are complex you might consider using a more advanced product that is designed to run complex schedules (distributed over multiple servers) and that supports triggers, job dependencies, error handling, retries and retry monitoring etc. The industry jargon would be "enterprise" job scheduling and/or "workload automation".

Específico do PHP

Se você tiver algum trabalho cron como:

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

E em caso de erros, espere que eles sejam enviados a você, mas não - verifique isso.

PHP por padrão não envia erros para STDOUT. @veja https://bugs.php.net/bug.php?id=22839

Para corrigir isso, adicione no php.ini do cli ou na sua linha (ou no seu bash wrapper para PHP) estes:

• --define display_startup_errors=1
• --define display_errors='stderr'

A 1ª configuração permitirá que você tenha fatais como 'Memory oops' e a 2ª - para redirecioná-los todos para STDERR. Somente depois que você pode dormir bem, todos serão enviados para o e-mail do seu root em vez de apenas logados.

Adding my answer from here for completeness, and adding another potentially helpful resource:

The cron user has a different $PATH than you do:

A frequent problem users make with crontab entries is that they forget that cron runs in a different environment than they do as a logged-in user. For example, a user creates a program or script in his $HOME directory, and enters the following command to run it:

$ ./certbot ... 

The command runs perfectly from his command line. The user then adds that command to his crontab, but finds this does not work:

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

The reason for the failure in this case is that ./ is a different location for the cron user than it is for the logged-in user. That is, the environment is different! The PATH is part of the environment, and it is usually different for the cron user. Complicating this issue is that the environment for cron is not the same for all *nix distributions, and there are multiple versions of cron

A simple solution to this particular problem is to give the cron user a complete path specification in the crontab entry:

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

What is the cron user's environment?

In some instances, we may need to know the complete environment specification for cron on our system (or we may just be curious). What is the environment for the cron user, and how is it different from ours? Further, we may need to know the environment for another cron user - root for example... what is the root user's environment using cron? One way to learn this is to ask cron to tell us:

1. Create a shell script in your home directory (~/) as follows (or with the editor of your choice):

$ nano ~/envtst.sh

2. Enter the following in the editor, after adjusting for your system/user:

#!/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

3. Save the file, exit the editor and set file permissions as executable.

$ chmod a+rx ~/envtst.sh

4. Run the script you just created, and review the output in /home/you/envtst.sh.out. This output will show your current environment as the $USER you're logged in as:

$ ./envtst.sh $$ cat /home/you/envtst.sh.out

5. Open your crontab for editing:

$ crontab -e -u root

6. Enter the following line at the bottom of your crontab:

* * * * *  /home/you/envtst.sh >> /home/you/envtst.sh.err 2>&1

ANSWER: The output file /home/you/envtst.sh.out will contain a listing of the environment for the "root cron user". Once you know that, adjust your crontab entry accordingly.

I can't specify the schedule I need in my crontab entry:

The schedule entry for crontab is of course defined in man crontab, and you should read this. However, reading man crontab, and understanding the schedule are two different things. And trial-and-error on a schedule specification can become very tedious. Fortunately, there is a resource that can help: the crontab guru.. Enter your schedule specification, and it will explain the schedule in plain English language.

Finally, and at risk of being redundant with one of the other answers here, do not get trapped into thinking that you are limited to a single crontab entry because you have one job to schedule. You are free to use as many crontab entries as you need to get the schedule you need.

As @Seamus said, 99% of my crontab problems come from having different environmental variables or different PATH variables so crontab can't find the script and it fails silently. Therefore my solution was to write a wrapper script that would:

1. Sets the PATH variable to the same one I'm used to
2. Sets my PYTHONPATH to my custom one to include all of my common functions
3. Changes the DISPLAY AND DBUS variables so that gui apps like notify-send messages actually make it to the screen
4. Changes the current working directory to the same one as the script. (If applicable)
5. Launches the script with nice ionice -c3 to save on resources.
6. Logs the stdout and stderr of the script in the "logs" directory so that when something goes wrong I can actually find out what happened.

Now if I want to launch a script I just edit mycrontab with crontab -e to:

 mm hh * * * /path-to.../cron.launcher.py script.name.sh

and it runs the script just as if I was trying to from the terminal without any aggravation. This was originally a BASH script, but it got hung up on arguments with spaces so I rewrote it all in python. It will even launch GUI apps into the userspace:

#!/usr/bin/python3

# Runtime directories:
SYSPATH = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
PYTHONPATH = ""

################################################################################
import os
import time
import sys
import subprocess

# Get username passed by crontab
user = os.environ['LOGNAME']
uid = subprocess.check_output(('id -u ' + user).split()).decode().strip()
gid = subprocess.check_output(('id -g ' + user).split()).decode().strip()

# Set Environmental Variables:
os.environ["PATH"] = SYSPATH
os.environ["PYTHONPATH"] = PYTHONPATH
os.environ["DISPLAY"] = ":0"
os.environ["XAUTHORITY"] = os.path.join('/home', user, '.Xauthority')
os.environ["DBUS_SESSION_BUS_ADDRESS"] = 'unix:path=' + os.path.join('/run/user', uid, 'bus')
os.environ["XDG_RUNTIME_DIR"] = os.path.join("/run/user", uid)

# Get args:
script = sys.argv[1]
args = sys.argv[2:]
name = os.path.basename(script)
basedir = os.path.dirname(sys.argv[0])

# Log dir
logdir = os.path.join(basedir, 'cron.logs')
log = os.path.join(logdir, name + '.' + str(int(time.time())) + '.log')
os.makedirs(logdir, exist_ok=True)
if not os.access(logdir, os.W_OK):
    print("Can't write to log directory", logdir, file=sys.stderr)
    sys.exit(1)

# If running as root, lock up any scripts so others can't edit them before root runs them.
if os.geteuid() == 0:
    cron_log = os.path.join(logdir, 'cron.launcher.root.log')
    for path in [script, sys.argv[0]] + list(filter(None, PYTHONPATH.split(':'))):
        print("Setting permisisons for", path)
        subprocess.run(('chown root -R ' + path).split(), stderr=subprocess.PIPE, check=False)
        subprocess.run(('chmod og-w -R ' + path).split(), stderr=subprocess.PIPE, check=False)
else:
    cron_log = os.path.join(logdir, 'cron.launcher.log')
cron_log = open(cron_log, 'a')
logger = lambda *args: cron_log.write(' '.join(map(str, args)) + '\n')

# Run the script
output = open(log, mode='w')
if os.path.exists(script):
    os.chdir(os.path.dirname(script))
cmd = ['nice', 'ionice', '-c3'] + [script] + args
logger(time.strftime('\n%m-%d %H:%M', time.localtime()).lstrip('0'), user, "running:")
logger(cmd)
logger("in directory", os.getcwd(), "with log in", log)
start = time.time()
ret = subprocess.run(cmd, stdout=output, stderr=output, check=False)

# Cleanup
fmt = lambda num: ("{0:.3g}").format(num) if abs(num) < 1000 else str(int(num))
logger("Returned", ret.returncode, "after", fmt(time.time() - start), 'seconds')
output.close()
cron_log.close()

Make sure you double check your $PATH and $PYTHONPATH variables in case you need to edit them to be different.