Eu tenho um script cron personalizado que é executado diariamente em um pi de framboesa. Ele é executado todas as noites às 20h, mas falha a cada vez em um determinado comando no script. No entanto, quando eu faço login como root ( sudo su ) e inicio o script, ele sempre funciona bem. Então eu manualmente não consigo acionar o erro, mas tenho que esperar cada vez que a tarefa do cron for executada, para solucioná-lo (sem sucesso, até agora).
Pergunta: O que mais posso fazer para simular melhor o comportamento e o contexto do script que está sendo executado em um cron job?
O script monta um compartilhamento NFS (hospedado no meu synology NAS), sincroniza algumas contas imap IMAP com o compartilhamento NFS e, em seguida, confirma o novo estado usando o mercurial.
me@mango:/etc/cron.daily8pm$ ls -l
total 4
-rwxr-xr-x 1 root root 1722 Jun 6 22:08 backupimaps
me@mango:/etc/cron.daily8pm$
Mostrando a parte relevante do roteiro:
me@mango:/etc/cron.daily8pm$ sed -n '38,47p' backupimaps
echo Performing IMAP backup\(s\)
#use basic interface (=noninteractive, good for cron)
offlineimap -u basic -c /etc/offlineimaprc
if [ $? -eq 0 ]; then
echo "Committing changes (addremove)..."
hg addremove --verbose -R $MOUNTDIR <--- failure on this command
echo "Committing changes (real commit)..."
hg commit -u "cronjob $USERNAME @ $HOSTNAME" -m "Autocommit @ $TIMESTAMP" -R $MOUNTDIR
else
me@mango:/etc/cron.daily8pm$
Quando executado como trabalho cron, ele sempre falha na linha hg addremove --verbose -R $MOUNTDIR com uma instrução abort: Permission denied... , continuando para a próxima instrução.
Isso faz parte da saída da tarefa cron do email
...
***** Finished processing account fmklaske
Committing changes (addremove)...
removing fmxxxxx/INBOX.Archief/cur/1439586438_1.7100.voyage,U=3233,FMD5=178b19d5fa680033b330f587796f66de:2,S
...
adding fmyyyy/INBOX/new/1496858746_2.3294.mango,U=59804,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
abort: Permission denied: '/mnt/imapbackup/fmxxxxx/INBOX.HOTMAIL OUD/cur/1496858720_0.3294.mango,U=18109,FMD5=7ae3c37de1c6bb870abee958daf1c6f6:2,S'
Committing changes (real commit)...
nothing changed (37 missing files, see 'hg status')
Eu não tenho idéia do porquê ele falha, pois quando eu executo o trabalho manualmente, ele é concluído com êxito e confirma os arquivos alterados conforme o esperado. Além disso, a mensagem de email que reporta falhar não é especial e as permissões parecem OK.
Para mais contexto:
me@mango:/etc/cron.daily8pm$ sudo tail -n 3 /var/log/cron.log
Jun 7 19:17:01 mango CRON[3231]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jun 7 20:05:01 mango CRON[3284]: (root) CMD ( test -x /usr/sib/anacron/ || ( cd / && run-parts --report /etc/cron.daily8pm ))
Jun 7 20:17:01 mango CRON[3431]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
E meu arquivo crontab
me@mango:/etc$ cat crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the 'crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
05 20 * * * root test -x /usr/sib/anacron/ || ( cd / && run-parts --report /etc/cron.daily8pm )
#
me@mango:/etc$
Nota: enquanto escrevo, notei o erro no caminho /usr/sib/anacron na última linha. Eu apenas consertei, mas isso não deve ter efeito algum IMO
Tags cron