Unterschied zwischen crontab und /etc/cron.hourly,daily,weekly

Ich habe ein geplantes Skript, das stündlich eine svnsync-Sicherung unserer Subversion-Repositorys durchführt. Ich habe es ohne Probleme von einem Eintrag in der Root-Crontab ausgeführt, aber ich habe beschlossen, es aus /etc/cron.hourly auszuführen, um zusätzliche Sichtbarkeit zu erreichen (und weil einer unserer Ingenieure die Crontab versehentlich gelöscht hat, weil er dachte, "crontab" -r "meinte" die crontab lesen ;-))

Die svnsync-Befehle im cron.hourly-Skript schlagen alle mit der Meldung fehl, dass das SSL-Zertifikat für das SVN-Repository akzeptiert werden muss (dies ist die Nachricht, die Sie interaktiv erhalten, wenn der Benutzer zum ersten Mal auf das SVN-Repository zugreift, aber einmal auf das Zertifikat I akzeptierte die Nachricht kommt nicht wieder).

Daher scheint es mir, dass das Skript unter einer anderen Benutzerumgebung ausgeführt wird, wenn es von cron.hourly ausgeführt wird, als wenn es über die root-crontab ausgeführt wird. Kann jemand den Unterschied erklären?

UPDATE: Ich hätte meine Distribution erwähnen sollen, ich benutze anacron unter CentOS 5.1.

UPDATE 2: Vielen Dank für die Vorschläge bisher; Ich denke, das wird eher zu einer Subversion-Frage. Ich versuche immer, meine Umgebung in meine Skripte einzuschließen, aber das Problem hierbei ist, dass ich nicht sicher bin, in welcher Umgebung (oder in welcher Umgebung) SVN die Annahme des SSL-Zertifikats verlangt, wenn ich mein Skript ausführe cron.hourly. Ich vermute, es hat etwas mit der Art und Weise zu tun, wie das Run-Parts-Skript ausgeführt wird.

Sie möchten mit der Option '--config-dir' wissen lassen, wo sich das akzeptierte Zertifikat befindet (z. B. standardmäßig ~ / .subversion).

Trotzdem bin ich mir fast sicher, dass Sie svnsync besser über das Hooks / Post-Commit-Skript aufrufen sollten, wie an anderer Stelle vorgeschlagen . Dann ist Ihr Spiegel immer synchron und nicht synchron mit dem Ort, an dem Ihr Master vor einer Stunde war.

Unter Debian / Ubuntu werden cron.daily | week | montly von der Haupt-crontab aus gestartet.

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 )

Denken Sie auch daran, dass Sie wahrscheinlich ein Crontab-Fragment in /etc/cron.d/ platzieren könnten.

Wie Sie sehen, hat diese Umgebung nichts Besonderes. Zumindest unter Debian / Ubuntu wird alles als Root-Account ausgeführt.

Wenn ich am Anfang des Skripts Cron-Skripte schreibe, setze ich immer meinen PATH und andere Umgebungsvariablen, die ich verwenden werde, damit ich sicher sein kann, dass es in jeder Umgebung korrekt funktioniert.

Eine reguläre systemweite Crontab ist die Crontab eines bestimmten Benutzers und hat das Feld Benutzername, wie es von verwendet wird /etc/crontab.

Die Verwendung von Skripten /etc/cron.*(stündlich, täglich, wöchentlich, monatlich) ist eine übersichtlichere und einfachere Methode (um häufige Syntaxfehler zu vermeiden), um crontab für rootBenutzer zu konfigurieren. Dabei werden run-partsSkripte oder Programme in einem Verzeichnis ausgeführt. Alle diese Regeln sind weiterhin standardmäßig in der systemweiten crontab ( /etc/crontab) definiert, daher ist es dasselbe.

Wenn Cron - Jobs durch behandelt werden run-parts, sind einfacher zu debuggen, wie Sie können einfach testen , welche Skripte genau laufen würde (ohne sie noch läuft) von:

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

Meine erste Vermutung wäre, Ihre HOME-Variable zu überprüfen.

Auf meinem Centos-System sagt Mann 5 Crontab:

Mehrere Umgebungsvariablen werden vom Daemon cron (8) automatisch eingerichtet. SHELL wird auf / bin / sh gesetzt, und LOGNAME und HOME werden in der Zeile / etc / passwd des Besitzers der crontab festgelegt.

Wenn Sie also nichts anderes angegeben haben, würde die crontab von root / root für HOME verwenden. In / etc / crontab (von wo aus /etc/cron.hourly über run-parts ausgeführt wird) wird HOME auf / gesetzt (und SHELL auf / bin / bash anstelle von / bin / sh).

Ich kenne svnsync nicht, aber subversion verwendet ein directory / .subversion / -Verzeichnis, das von HOME abhängen könnte.

Auf meinem RHEL 5.1-System wird die Umgebungsvariable PATH in / etc / crontab festgelegt. Das ganze Zeug oben ist Zeug, das in die Umwelt eingespeist wird.

Wenn Sie cron neu starten, wird es beim ersten Start (wenn von /etc/crontaboder /var/spool/cron/$USER) in / var / log / cron notiert. Andernfalls wird nur bemerkt, dass cron.hourly lief

Meine Crontab ist auf Folgendes eingestellt:

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

Sie könnten Folgendes in /etc/cron.hourly einfügen:

env > /tmp/cron.env

Untersuchen Sie dann die Datei, wenn sie verfügbar ist, und ändern Sie entweder Ihr Skript (falls möglich), um die Umgebung richtig einzustellen, oder schreiben Sie ein kurzes Wrapper-Skript, das Ihre crontab aufruft.

/var/log/messages (oder das Äquivalent Ihrer Distribution) sollte Ihnen mitteilen, welcher Befehl wann und als welcher Benutzer ausgeführt wurde.

Niemals davon ausgehen, dass sich etwas in der Umgebung befindet. Code immer defensiv. Sie haben eine ganze Datei, in der Sie alles ablegen können, was Sie für die Einrichtung der Umgebung benötigen. Benutze es.

Nicht viel anders als die Portabilität, das letzte Mal, als ich (in Debian) nachgesehen habe, wurde empfohlen, Sachen in cron.hourly (und die anderen) abzulegen und nicht direkt in crontab, wenn Sie ein Paket mit Ihren Sachen erstellen wollten.