Eu tenho um servidor Ubuntu com um único usuário e o seguinte crontab:
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and crontab(8)
#
# m h dom mon dow command
MAILTO=<my email>
* * * * * echo "Test"
Por mais simples que seja esta tarefa do cron, não recebo emails. Eu também tentei modificá-lo da seguinte forma (no caso de haver um problema com meu email):
* * * * * echo "Test" >> test.txt
mas o arquivo test.txt nunca é criado.
Isso parece ser um problema simples realmente , mas normalmente, quando tenho problemas com os trabalhos do cron, ele realmente está em execução e o trabalho está apenas gerando um erro. Não sei como começar a diagnosticar quando o trabalho nem está em execução.
service cron status
sbarnett@sbarnett:~$ service cron status
Failed to get properties: Access denied
sbarnett@sbarnett:~$ sudo service cron status
[sudo] password for sbarnett:
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2017-08-15 14:15:52 MST; 3 weeks 1 days ago
Docs: man:cron(8)
Main PID: 1682 (cron)
CGroup: /system.slice/cron.service
└─1682 /usr/sbin/cron -f
Sep 07 09:55:01 sbarnett.vm CRON[3144]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 09:55:01 sbarnett.vm CRON[3145]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Sep 07 10:05:01 sbarnett.vm CRON[3151]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 10:05:01 sbarnett.vm CRON[3152]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Sep 07 10:05:01 sbarnett.vm CRON[3151]: pam_unix(cron:session): session closed for user root
Sep 07 10:15:01 sbarnett.vm CRON[3156]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 10:15:01 sbarnett.vm CRON[3157]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Sep 07 10:17:01 sbarnett.vm CRON[3159]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 10:17:01 sbarnett.vm CRON[3160]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 07 10:17:01 sbarnett.vm CRON[3159]: pam_unix(cron:session): session closed for user root
No Ubuntu o crontab é um pouco diferente, existe um campo "usuário" após o seletor de tempo ...
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
Para depurar, você pode tentar usar um comando simples, como:
logger "This goes to /var/log/syslog"
E verifique se vai para esse arquivo de log nos horários esperados. Em seguida, chame um script (um script que em si chama logger ...)
Meu problema específico parecia ser estranho, com detalhes completos dos quais eu não entendo completamente - mas através de algumas suposições e da leitura de vários posts no fórum eu encontrei a resposta.
Às vezes, as atualizações do SO podem estragar com as permissões em seus arquivos cron. Qualquer (ou todos) dos seguintes itens pode corrigir:
sudo service cron reload sudo service cron restart sudo /etc/init.d/cron restart shutdown -r now sudo apt-get dist-upgrade Basicamente: