Differenza tra l'utilizzo di crontab e /etc/cron.hourly, giornaliero, settimanale

Ho uno script programmato che esegue un backup svnsync orario dei nostri repository Subversion. Lo stavo eseguendo da una voce nel crontab di root senza problemi, ma ho deciso che mi piacerebbe eseguirlo da /etc/cron.hourly invece per maggiore visibilità (e perché uno dei nostri ingegneri ha accidentalmente eliminato il crontab perché pensava "crontab -r "intendeva" leggere il crontab ;-))

I comandi svnsync nello script cron.hourly falliscono tutti con un messaggio che dice che il certificato SSL per il repository SVN deve essere accettato (questo è il messaggio che ricevi in ​​modo interattivo la prima volta che l'utente accede al repository SVN, ma una volta che il certificato I ha accettato che il messaggio non venga più visualizzato).

Quindi mi sembra che lo script venga eseguito in un ambiente utente diverso quando viene eseguito da cron.hourly rispetto a quando viene eseguito tramite crontab root. Qualcuno può spiegare la differenza?

AGGIORNAMENTO: avrei dovuto menzionare la mia distribuzione, sto usando anacron su CentOS 5.1.

AGGIORNAMENTO 2: Grazie per i suggerimenti finora; Penso che questo si stia trasformando in più di una domanda di Subversion. Cerco sempre di incapsulare il mio ambiente nei miei script, ma il problema qui è che non sono sicuro di cosa sia (o che manchi) nell'ambiente che fa sì che SVN richieda l'accettazione del certificato SSL quando eseguo il mio script da cron.hourly. Immagino che abbia a che fare con il modo in cui viene eseguito lo script run-parts.

Si desidera utilizzare l'opzione '--config-dir' per far sapere dove trovare il certificato accettato (ad esempio ~ / .subversion per impostazione predefinita).

Detto questo, sono quasi certo che faresti meglio a chiamare svnsync dallo script hook / post-commit, come suggerito altrove . Quindi il tuo mirror è sempre sincronizzato, piuttosto che sincronizzato con dove il tuo master era un'ora fa.

Sul sistema Debian / Ubuntu cron.daily | Weekly | montly vengono avviati dal crontab principale.

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 )

Inoltre, tieni presente che probabilmente potresti inserire un frammento crontab in /etc/cron.d/

Come puoi vedere non c'è nulla di particolarmente speciale in questo ambiente. Almeno su Debian / Ubuntu tutto viene eseguito come account root.

Quando scrivo cron script all'inizio dello script, ho sempre impostato il mio PERCORSO e le altre variabili d'ambiente che userò, quindi posso essere certo che funzionerà correttamente in qualsiasi ambiente.

Un crontab normale a livello di sistema è un crontab di un utente specifico e ha il campo username, come usato da /etc/crontab.

L'uso degli script in /etc/cron.*(orario, giornaliero, settimanale, mensile) è un modo più semplice e pulito (previene errori di sintassi comuni) di configurare crontab per l' rootutente e questo viene gestito tramite il run-partsquale eseguire script o programmi in una directory. Tutte queste regole sono ancora definite in crontab a livello di sistema per impostazione predefinita ( /etc/crontab), quindi è la stessa cosa.

Quando i lavori cron sono gestiti da run-parts, sono più facili da eseguire il debug, in quanto puoi semplicemente testare quali script sarebbero esattamente eseguiti (senza eseguirli ancora) da:

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

La mia prima ipotesi selvaggia sarebbe controllare la tua variabile HOME.

Sul mio sistema Centos, man 5 crontab dice:

Diverse variabili di ambiente vengono impostate automaticamente dal demone cron (8). SHELL è impostato su / bin / sh e LOGNAME e HOME sono impostati dalla riga / etc / passwd del proprietario del crontab.

Quindi, se non specificato diversamente, il crontab di root userebbe / root per HOME. Ma in / etc / crontab (che è da dove viene eseguito /etc/cron.hourly, tramite run-parts), HOME è impostato su / (e SHELL su / bin / bash anziché / bin / sh).

Non conosco svnsync, ma Subversion usa una directory ˜ / .subversion /, quindi potrebbe dipendere da HOME.

Sul mio sistema RHEL 5.1, la variabile d'ambiente PATH è impostata da / etc / crontab. Tutta quella roba in alto è roba che viene immessa nell'ambiente.

Se riavvii cron, la prima volta che viene eseguito (se da /etc/crontabo /var/spool/cron/$USER) ne prenderà nota in / var / log / cron. Altrimenti noterà semplicemente che cron.hourly ha funzionato

Il mio crontab è impostato come segue:

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

Quello che potresti fare è mettere qualcosa come il seguente in /etc/cron.hourly:

env > /tmp/cron.env

Quindi ispeziona il file quando arriva e modifica lo script (se puoi) per impostare correttamente l'ambiente, oppure scrivi uno script wrapper breve che chiamerà il tuo crontab.

/var/log/messages (o l'equivalente della tua distro) dovrebbe dirti i dettagli di quale comando è stato eseguito quando e come quale utente.

Non dare mai per scontato che ci sia qualcosa nell'ambiente. Codice sempre difensivo. Hai un intero file per mettere qualsiasi ambiente impostare cose che vuoi lì. Usalo

Non molto altro la portabilità, l'ultima volta che ho controllato (in Debian) mi è stato consigliato di mettere roba in cron.hourly (e le altre) e non direttamente in crontab se volevi creare un pacchetto con le tue cose.