Ich habe ein geplantes Skript, das stündlich ein svnsync-Backup unserer Subversion-Repositorys durchführt. Ich habe es ohne Probleme von einem Eintrag in der Root-Crontab aus ausgeführt, habe mich dann aber entschieden, es lieber von /etc/cron.hourly aus auszuführen, um die Übersichtlichkeit zu erhöhen (und weil einer unserer Ingenieure die Crontab versehentlich gelöscht hat, weil er dachte, „crontab -r“ bedeute „die Crontab lesen ;-))
Die svnsync-Befehle im Skript cron.hourly schlagen alle mit der Meldung fehl, dass das SSL-Zertifikat für das SVN-Repository akzeptiert werden muss (dies ist die Meldung, die Sie interaktiv erhalten, wenn der Benutzer zum ersten Mal auf das SVN-Repository zugreift, aber sobald das Zertifikat akzeptiert wurde, wird die Meldung nicht erneut angezeigt).
Mir scheint also, dass das Skript in 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 verwende Anacron auf CentOS 5.1.
UPDATE 2: Danke für die bisherigen Vorschläge; ich glaube, das wird eher zu einer Subversion-Frage. Ich versuche immer, meine Umgebung in meine Skripte einzubinden, aber das Problem hier ist, dass ich nicht sicher bin, was in der Umgebung ist (oder fehlt), das SVN dazu veranlasst, die Annahme des SSL-Zertifikats anzufordern, wenn ich mein Skript von cron.hourly aus ausführe. Ich vermute, es hat etwas mit der Art und Weise zu tun, wie das Skript „run-parts“ ausgeführt wird.
Antwort1
Sie möchten die Option „–config-dir“ verwenden, um mitzuteilen, wo das akzeptierte Zertifikat zu finden ist (standardmäßig z. B. ~/.subversion).
Dennoch bin ich mir ziemlich sicher, dass es besser wäre, svnsync stattdessen aus dem Hooks/Post-Commit-Skript aufzurufen, daanderswo vorgeschlagen. Dann ist Ihr Spiegel immer synchron und nicht mit dem Stand Ihres Masters vor einer Stunde.
Antwort2
Auf Debian/Ubuntu-Systemen werden cron.daily|weekly|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 )
Bedenken Sie auch, dass Sie wahrscheinlich ein Crontab-Fragment in /etc/cron.d/ platzieren könnten
Wie Sie sehen, ist an dieser Umgebung nichts besonders Besonderes. Zumindest unter Debian/Ubuntu wird alles als Root-Konto ausgeführt.
Wenn ich Cron-Skripte schreibe, lege ich ganz am Anfang des Skripts immer meinen PATH und andere Umgebungsvariablen fest, die ich verwenden werde, sodass ich sicher sein kann, dass es in jeder Umgebung ordnungsgemäß funktioniert.
Antwort3
Eine reguläre systemweite Crontab ist die Crontab eines bestimmten Benutzers und verfügt über 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 sauberere und einfachere Möglichkeit (verhindert häufige Syntaxfehler), Crontab für rootBenutzer zu konfigurieren. Dies wird dadurch erledigt, run-partsdass Skripte oder Programme in einem Verzeichnis ausgeführt werden. Alle diese Regeln sind standardmäßig immer noch in der systemweiten Crontab definiert ( /etc/crontab), es ist also dasselbe.
Wenn Cron-Jobs von gehandhabt werden run-parts, sind sie leichter zu debuggen, da Sie einfach testen können, welche Skripte genau ausgeführt werden (ohne sie bereits auszuführen), indem Sie:
sudo run-parts --report --test /etc/cron.daily
Antwort4
Auf meinem RHEL 5.1-System wird die Umgebungsvariable PATH über /etc/crontab festgelegt. All das Zeug da oben ist Zeug, das in die Umgebung eingespeist wird.
Wenn Sie cron neu starten, wird es beim ersten Ausführen (wenn von /etc/crontaboder /var/spool/cron/$USER) eine Notiz in /var/log/cron machen. Andernfalls wird nur vermerkt, dass cron.hourly ausgeführt wurde.
Meine Crontab ist wie folgt 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 beispielsweise Folgendes in /etc/cron.hourly einfügen:
env > /tmp/cron.env
Überprüfen 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 von Ihrer Crontab aufgerufen wird.