Como sei se o crontab está funcionando bem?

Question

Existe um log de crontab para eu saber se o crontab está funcionando bem? Eu estou no Linux Mint 17.3.

O que eu fiz:

1. executou crontab -e como raiz
2. ele não existia, então eu escolhi nano editor e continuei
3. entrou nesta linha 00 12 * * * /home/vlastimil/Development/bash/full-upgrade.sh
4. salvo e finalizado

Meu objetivo é automatizar as atualizações todos os dias às 12 horas (meio-dia, não à meia-noite). Este tópico não é sobre argumentar a melhor maneira de conseguir isso.

Eu criei o arquivo /home/vlastimil/Development/bash/full-upgrade.sh com o conteúdo:

#!/bin/bash
apt-get update && apt-get dist-upgrade -y && apt-get --purge autoremove -y

E finalmente eu defini 755 direitos para o arquivo.

Eu não sei como testá-lo. Isso funcionará?

    

Answer 1

Logs provavelmente vão para o syslog, que varia dependendo do que o daemon syslog está envolvido e como isso é configurado para logar, comece com

grep -r cron /etc/*syslog*

para encontrar onde e o que está acontecendo no sistema, ou por exemplo em systemd o comando relevante é

journalctl -b 0 _SYSTEMD_UNIT=cron.service

Adicionar uma tarefa cron do teste que toca um arquivo (idealmente não em /tmp , a menos que o fornecedor torne esse usuário privado, por motivos de segurança) também deve confirmar se o cron está funcionando ou não, o trabalho do cron cron antes de preencher uma partição ou algo bobo.

Outros indicadores de usabilidade e segurança: alguns daemons do cron podem executar scripts diretamente, e nesse caso você pode simplesmente copiar o script em /etc/cron.daily , embora isso possa não ser adequado para algo que você não deseja executar (com tudo mais!) exatamente no topo da hora. root executar um script no diretório inicial de um usuário pode ser muito ruim, pois um comprometimento dessa conta de usuário poderia ser aproveitado para o acesso root ou o script poderia falhar desnecessariamente se o diretório inicial estivesse em NFS ou criptografado; mova o script para outro lugar para evitar isso ( /root/bin , ou algum lugar abaixo de /usr/local ou /opt dependendo das preferências do sistema de arquivos local).

Ainda mais ponteiros caem no reino da depuração do shell script, principalmente para notar que o cron não é o shell; use env ou set para ver o que está configurado no cron, verifique se PATH está correto e etc. (Um bug antigo e horrível do kernel do linux envolvia daemons java travando, mas apenas se eles fossem executados a partir do cron; divertido de depurar ...)