Eu tenho um script agendado que faz um backup svnsync de hora em hora dos nossos repositórios do Subversion. Eu estava rodando a partir de uma entrada no crontab raiz sem problemas, mas decidi que gostaria de executá-lo de /etc/cron.hourly em vez de visibilidade extra (e porque um dos nossos engenheiros apagou acidentalmente o crontab porque ele pensou "crontab -r "significou" leia o crontab; -))
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ê obtém interativamente na primeira vez que o usuário acessa o repositório SVN, mas uma vez o certificado que eu aceitei a mensagem não aparece novamente).
Então, 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?
UPDATE: Eu deveria ter mencionado minha distro, estou usando o anacron no CentOS 5.1.
UPDATE 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 eu não tenho certeza do que é (ou falta) no ambiente que faz com que o SVN solicite que o certificado SSL seja aceito quando eu executar meu script de cron.hourly. Eu estou supondo que é algo a ver com a maneira que o script run-parts é executado.
Você deseja usar a opção '--config-dir' para informar onde encontrar o certificado aceito (por exemplo, ~ / .subversion por padrão).
Dito isto, estou quase certo de que seria melhor chamar o svnsync do script hooks / post-commit, como sugerido em outro lugar . Então seu espelho está sempre em sincronia, em vez de estar em sincronia com o lugar onde seu mestre estava há uma hora.
No sistema Debian / Ubuntu, o cron.daily | weekly | 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 )
Tenha em mente que você provavelmente poderia colocar um fragmento de crontab em /etc/cron.d /
Como você pode ver, não há nada de especial nesse ambiente. Pelo menos no Debian / Ubuntu tudo é executado como a conta root.
Quando eu escrevo scripts cron no início do script, eu sempre configuro o meu PATH e outras variáveis de ambiente que eu vou usar, então posso ter certeza que funcionará corretamente em qualquer ambiente.
Um crontab regular em todo o sistema é um crontab de um usuário específico e tem o campo username, como usado por /etc/crontab .
Usar scripts em /etc/cron.* (por hora, diariamente, semanalmente, mensalmente) é uma maneira mais limpa e fácil (evita erros comuns de sintaxe) de configurar o crontab para root user e isso é tratado por run-parts que executa scripts ou programas em um diretório. Todas essas regras ainda são definidas no crontab do sistema por padrão ( /etc/crontab ), então é a mesma coisa.
Quando tarefas cron são manipuladas por run-parts , é mais fácil depurar, já que você pode simplesmente testar quais scripts seriam executados com exatidão (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, man 5 crontab diz:
Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab’s owner.
Portanto, se você não especificou o contrário, o crontab do root usaria / root para HOME. Mas em / etc / crontab (que é onde o /etc/cron.hourly é executado, via run-parts), HOME é setada para / (e SHELL para / bin / bash ao invés de /bin/sh).
Eu não sei sobre o svnsync, mas o subversion usa um diretório ˜ / .subversion /, então isso pode depender de 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 colocadas no ambiente.
Se você reiniciar o cron, a primeira vez que ele for executado (se for de /etc/crontab ou /var/spool/cron/$USER ), ele fará uma anotação em / var / log / cron. Caso contrário, apenas notará que o cron.hourly executou
Meu crontab está definido para o seguinte:
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ê poderia fazer é colocar algo como o seguinte em /etc/cron.hourly:
env > /tmp/cron.env
Em seguida, inspecione o arquivo quando ele se aproximar e modifique seu script (se puder) para definir o ambiente corretamente ou escreva um script de wrapper pequeno que seu crontab chamará.
/var/log/messages (ou o equivalente da sua distro) deve informar as especificidades de qual comando foi executado quando e como usuário.
Nunca assuma que existe algo no ambiente. Sempre codifique defensivamente. Você tem um arquivo inteiro para colocar qualquer ambiente que você quiser. Use-o.
Não muito mais a portabilidade, a última vez que eu 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 suas coisas. / p>