Altere a entrada perl para path/to/perl . Muitas vezes, comandos como perl e python são realmente baseados no ambiente e são encontrados em seu PATH. Como o cron não tem esse PATH, é melhor usar caminhos absolutos no crontab.
Eu tenho 3 entradas do cronjob ( crontab -l ) a primeira entrada é um script Perl que cria um backup LVM de uma máquina virtual e os outros dois são apenas arquivos sh que executam mysqldump .
Bem, porém, editei crontab -e como root ( sudo su first) e esta é minha primeira entrada de trabalho
# Run daily backup of my job at 3:15 [relation ä11]
15 3 * * * perl /opt/AUTO_BACKUP/virt-backup.pl --action=dump --date --vm=SERVER2
Bem, mas ele não cria nenhuma saída no diretório de backup nem nenhuma entrada nos registros do cron. Nos arquivos de log do cron, encontrei apenas entradas das outras tarefas sh.
Mas quando eu copio o comando perl /opt/AUTO_BACKUP/virt-backup.pl --action=dump --date --vm=SERVER2 direto para o terminal raiz, ele funciona como um encanto. Então, como edito crontab como root, apenas o usuário certo deve executar o trabalho. E também não há erros no log.
Altere a entrada perl para path/to/perl . Muitas vezes, comandos como perl e python são realmente baseados no ambiente e são encontrados em seu PATH. Como o cron não tem esse PATH, é melhor usar caminhos absolutos no crontab.
O motivo pelo qual o script é executado ao ser executado a partir do shell, mas não como um cronjob, geralmente é o env diferente que ele encontra lá.
Portanto, altere seu cronjob para salvar o env em, por exemplo. / tmp / env usando
env | sort> /tmp/env
e quando / tmp / env chega ao diff com seu env atual
env | sort | diff - /tmp/env
HTH