Usei essas 2 referências para inserir uma nova entrada no crontab.
Eu criei um novo arquivo bash e movi-o para/usr/bin. Esse arquivo sh possui permissões de execução para o usuário root e o grupo admin. O arquivo bash apenas ecoa uma linha em um arquivo de log e depois chama um programa java. Eu testei o arquivo sh como root, manualmente. Funciona bem. Minha entrada no crontab se parece com isso ...
@hourly /usr/bin/foo.blah.sh
É suposto funcionar no início de cada hora. A instrução echo não está sendo impressa no arquivo de log, então não acho que o crond a esteja chamando. Além disso, quando monitoro visualmente os processos no "topo", o trabalho nunca aparece. Executei "service crond status" para verificar se o daemon cron está em execução. A documentação diz que não é necessário reiniciar o daemon. O que mais eu poderia estar fazendo de errado?
Responder1
Na verdade, você não diz onde está a entrada do crontab, mas com base no seu comentário que crontab -lgera no crontab for root, eu arriscaria supor que você adicionou um arquivo em um dos diretórios /etc/cron.*, que contém arquivos correspondentes a vários cron empregos. Esta resposta pressupõe que seja esse o caso.
Esses arquivos têm um formato um pouco diferente do crontab específico do usuário que você edita por meio do crontab -e. Especificamente,eles incluem um campo de nome de usuáriologo antes do comando, que não está incluído no crontab específico do usuário (que pelo menos no meu sistema está armazenado em /var/spool/cron/crontabs, mas por favor não abuse dessa informação; a localização exata é um detalhe de implementação do daemon cron que você está executando e deve usar as interfaces documentadas para gerenciar esses arquivos).
Como resultado,você deveria mudar
@hourly /usr/bin/foo.blah.sh
para
@hourly user /usr/bin/foo.blah.sh
onde userestá o nome da conta de usuário para executar o script. Deve então funcionar bem.
Eu realmente encorajo você a não executar cron jobs, roota menos que seja necessário; fazer qualquer coisa como superusuário é sempre um risco de segurança. Se possível, dê ao script uma conta própria com acesso restrito. (Este é o princípio do menor privilégio; isto é, o mínimo necessário para que ele faça seu trabalho.) Como regra geral, você deve colocararquivos locais do sistema em /usr/localpara evitar conflitos com o gerenciador de pacotes do sistema; além disso, para evitar confusão, não coloque coisas em nenhum diretório bin que precise de privilégios de root para funcionar; em vez disso, use sbin.
Responder2
No passado, ao adicionar scripts ao cron, eu sempre liderava a linha com sh, assim:
@hourly sh /usr/bin/foo.blah.sh