Você precisa capturar a saída ilusória do crontab para poder ver o que está reclamando.
-
Adicione -x ao seu shebang para saída detalhada no seu script:
#!/bin/sh -x
-
Defina a tarefa cron para executar com mais frequência enquanto você soluciona problemas:
*/1 * * * * root /home/absolute/runsikulix -r /home/absolute/auto/test.sikuli
O Crontab deve estar logando em / var / log / syslog por padrão. Execute um grep CRON /var/log/syslog
e verifique a saída. Se você vir sua tarefa em execução, poderá tail -f
do syslog quando o cron rodar e ver do que está reclamando.
- Se a saída não for detalhada o suficiente, você poderá reconfigurar o cron para gerar um arquivo de log seguindo estas instruções. Essa é a maneira "correta" de fazer isso:
Configurando o crontab para registrar em um arquivo ...
Isso deve mostrar a você cada etapa que o crontab está executando para que você possa ver onde está a falha. Eu observarei que o ambiente do crontab é muito pequeno e você deve usar caminhos cheios em vez de relativos em seu script, já que quaisquer binários que você chamar podem ou não estar disponíveis em seu caminho quando ele é executado. Crontab é engraçado assim. Para contornar isso, você pode adicionar caminhos ao seu script:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
... ou você pode chamar cada binário usando seu caminho completo:
/bin/echo "say something" && /bin/which java
Você também pode chamar o ambiente de um usuário inline:
0 5 * * * . /root/.profile; /home/absolute/runsikulix -r /home/absolute/auto/test.sikuli
Aqui está um exemplo de script no formato de modelo Ruby executado sob o crontab do root que ilustra algumas soluções alternativas para lidar com os problemas do ambiente: