Diferença entre usar o crontab e /etc/cron.hourly,daily,weekly

Eu tenho um script agendado que faz um backup svnsync de hora em hora de nossos repositórios do Subversion. Eu estava executando-o a partir de uma entrada no crontab raiz sem problemas, mas decidi que gostaria de executá-lo em /etc/cron.hourly para obter visibilidade extra (e porque um de nossos engenheiros excluiu acidentalmente o crontab porque pensou "crontab -r "quis dizer" leia o crontab ;-))

Todos os comandos svnsync no script cron.hourly falham com uma mensagem dizendo que o certificado SSL para o repositório SVN precisa ser aceito (esta é a mensagem que você recebe interativamente na primeira vez que o usuário acessa o repositório SVN, mas uma vez que o certificado I aceito a mensagem não aparece novamente).

Portanto, parece-me que o script está sendo executado em um ambiente de usuário diferente quando executado a partir do cron.hourly do que quando é executado através do crontab raiz. Alguém pode explicar a diferença?

ATUALIZAÇÃO: Eu deveria ter mencionado minha distribuição, estou usando o anacron no CentOS 5.1.

ATUALIZAÇÃO 2: Obrigado pelas sugestões até agora; Eu acho que isso está se tornando mais uma questão do Subversion. Eu sempre tento encapsular meu ambiente em meus scripts, mas o problema aqui é que não sei ao certo o que é (ou o que falta) no ambiente que faz o SVN solicitar que o certificado SSL seja aceito quando eu executo o script. cron.hourly. Acho que tem algo a ver com a maneira como o script de partes de execução é executado.

Você deseja usar a opção '--config-dir' para que ele saiba onde encontrar o certificado aceito (por exemplo, ~ / .subversion por padrão).

Dito isso, tenho quase certeza de que seria melhor chamar svnsync a partir do script hooks / post-commit, como sugerido em outro lugar . Então seu espelho está sempre sincronizado, em vez de estar onde seu mestre estava há uma hora atrás.

No sistema Debian / Ubuntu, cron.daily | semanal | montly é iniciado a partir do crontab principal.

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 )

Lembre-se também de que você provavelmente pode colocar um fragmento crontab em /etc/cron.d/

Como você pode ver, não há nada de especial neste ambiente. Pelo menos no Debian / Ubuntu, tudo é executado como a conta root.

Quando escrevo scripts cron no início do script, sempre defino meu PATH e outras variáveis ​​de ambiente que vou usar, para ter certeza de que funcionará corretamente em qualquer ambiente.

Um crontab regular em todo o sistema é o crontab de um usuário específico e possui o campo de nome de usuário, conforme usado por /etc/crontab.

O uso de scripts /etc/cron.*(a cada hora, diariamente, semanalmente, mensalmente) é uma maneira mais limpa e fácil (evita erros comuns de sintaxe) de configurar o crontab para o rootusuário e isso é tratado pela run-partsexecução de scripts ou programas em um diretório. Todas essas regras ainda são definidas no crontab de todo o sistema por padrão ( /etc/crontab), então é a mesma coisa.

Quando os trabalhos cron são manipulados run-parts, é mais fácil depurar, pois você pode simplesmente testar quais scripts seriam executados exatamente (sem executá-los ainda):

sudo run-parts --report --test /etc/cron.daily

Meu primeiro palpite seria verificar sua variável HOME.

No meu sistema Centos, o man 5 crontab diz:

Várias variáveis ​​de ambiente são configuradas automaticamente pelo daemon cron (8). SHELL está definido como / bin / sh, e LOGNAME e HOME estão definidos na linha / etc / passwd do proprietário do crontab.

Portanto, se você não especificou o contrário, o crontab do root usaria / root para o HOME. Mas no / etc / crontab (que é o local de onde o /etc/cron.hourly é executado, via run-parts), HOME está definido como / (e SHELL em / bin / bash em vez de / bin / sh).

Eu não sei sobre o svnsync, mas o subversion usa um diretório ˜ / .subversion /, portanto isso pode depender do HOME.

No meu sistema RHEL 5.1, a variável de ambiente PATH é definida em / etc / crontab. Todas essas coisas no topo são coisas que são alimentadas no meio ambiente.

Se você reiniciar o cron, na primeira vez em que for executado (se for de /etc/crontabou /var/spool/cron/$USER), ele fará uma anotação em / var / log / cron. Caso contrário, apenas observe que o cron.hourly foi executado

Meu crontab está definido da seguinte forma:

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

O que você pode fazer é colocar algo como o seguinte em /etc/cron.hourly:

env > /tmp/cron.env

Em seguida, inspecione o arquivo quando ele aparecer e modifique seu script (se você puder) para definir o ambiente corretamente ou escreva um script de invólucro curto que seu crontab chamará.

/var/log/messages (ou o equivalente da sua distribuição) deve informar os detalhes de qual comando foi executado quando e como qual usuário.

Nunca assuma que exista algo no ambiente. Sempre codifique defensivamente. Você tem um arquivo inteiro para colocar o ambiente que você deseja configurar. Use-o.

Não muito diferente da portabilidade, na última vez que verifiquei (no Debian), foi recomendado colocar coisas no cron.hourly (e nos outros) e não diretamente no crontab, se você quisesse criar um pacote com as suas coisas.