Eu usei crontab -e para adicionar a seguinte linha ao meu crontab:
* * * * * echo hi >> /home/myusername/test
No entanto, não vejo que o arquivo de teste tenha sido gravado. Este é um problema de permissão ou o crontab não está funcionando corretamente?
Eu vejo que o processo do cron está sendo executado. Como posso depurar isso?
Editar - Pergunte ao Ubuntu uma boa pergunta sobre o crontab , infelizmente isso ainda não me ajuda.
Editar 2 - Hmm, parece que meu arquivo de teste tem 214 linhas, o que significa que nos últimos 214 minutos ele foi gravado a cada minuto. Não tenho certeza qual foi o problema, mas está evidentemente desaparecido.
Existem implementações de cron (nem todas, e não me lembro de qual improvisado, mas encontrei uma no Linux) que verifica se há arquivos atualizados de crontab a cada minuto, e não considera novas entradas até o próximo minuto. Portanto, um crontab pode levar até dois minutos para ser acionado pela primeira vez. Isso pode ser o que você observou.
Você adicionou uma linha vazia após o seu cronjob ?
Eu tive o mesmo problema - um crontab de trabalho parou de repente depois que eu adicionei uma nova entrada no final. Acontece que eu tinha esquecido de colocar uma nova linha depois dessa última linha.
Eu descobri ao emitir o comando
cat /var/log/syslog | grep crontab
e a saída mostrou o problema:
Jul 2 08:16:01 shiva cron[1254]: (*system*) RELOAD (/etc/crontab)
Jul 2 08:16:01 shiva cron[1254]: (*system*) ERROR (Missing newline before EOF, this crontab file will be ignored)
Adicionando a nova linha e salvando, corrigimos o problema.
Parece que isso é fixo. Da próxima vez, tente registrar o STDERR também. O seguinte só irá logar para STDOUT, não STDERR:
* * * * * echo hi >> /home/myusername/test
Tente garantir que também exista uma cláusula explícita para STDERR. Caso contrário, o STDERR pode ser enviado via e-mail para o usuário (supondo que o e-mail esteja funcionando) ou pode não levar a lugar nenhum, dependendo de como o Cron está configurado.
* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr
Minha preferência é enviar a saída do cronjob para syslog. Dessa forma, estou aproveitando qualquer infraestrutura syslog existente (syslogs centralizados, Splunk, rotação de logs já suportada, é fácil comparar mensagens em / var / log / messages & / var / log / cronjob, etc), e estou não spamming os sysadmins (eu) com e-mails desnecessários.
* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob
Sua linha cron funciona bem no meu computador quando eu altero myusernae para phunehehe . Existem várias maneiras de descobrir o que há de errado com seu sistema.
Normalmente, o Cron envia e-mails para o usuário quando há algo errado. Se você vir a mensagem "Você tem e-mail", use um cliente de e-mail para verifique sua caixa de entrada . Ou, no seu diretório home, pode haver um arquivo chamado dead.letter .
Você pode verificar /var/log/ para entradas relacionadas ao cron. No meu computador, o arquivo de log está em /var/log/cron/current (requer acesso root).
Se você tiver acesso root, poderá parar o daemon do cron e iniciá-lo no modo de depuração. Por exemplo, eu usaria (altere fcron para o nome do seu daemon):
killall fcron
fcron --foreground --debug
O mais provável é que, quando o cron falha, ele gera um email para o ID do usuário do cron job nesse computador. Se você não tiver um MTA trabalhando em seu computador, ou se não estiver lendo ou encaminhando esse email para outro local, não verá essa mensagem, mesmo que o MTA esteja funcionando.
Uma boa maneira de obter os erros do seu crontab via e-mail é fazer com que seu crontab fique assim:
MAILTO="[email protected]"
* * * * * echo hi >> /home/myusernae/test
Obviamente, use seu endereço de e-mail em vez de [email protected]. Isso informa ao cron para enviar erros ao seu endereço de e-mail, em vez da conta local. Em particular, isso é útil se você tiver um crontab raiz (ou um fragmento crontab em /etc/cron.d) que você deseja enviar a saída para você, você pode evitar o envio de spam pelo correio ou pelo endereço de redirecionamento do root.
Para mim, o problema era que o script não era executável. Eu tinha a configuração crontab -e como esta
* * * * * /bin/my-script.sh
E o arquivo myscript não era executável, então eu corri
chmod +x my-script.sh
Imediatamente comecei a ver a saída como esperado.
Eu acho que uma razão para isso pode ser que o diretório / home / esteja criptografado e quando o usuário está desconectado, o cron não pode fazer nada nesse diretório.
veja: link
Tags cron