Crontab ve /etc/cron.hourly,daily,weekly kullanma arasındaki fark


12

Subversion depolarımızın saatlik svnsync yedeklemesini yapan zamanlanmış bir komut dosyası var. Kök crontab'daki bir girişten sorunsuz bir şekilde çalıştırıyordum, ancak ekstra görünürlük için /etc/cron.hourly yerine çalıştırmaya karar verdim (ve mühendislerimizden biri crontab'ı yanlışlıkla sildi çünkü "crontab" -r "demek" crontab okumak ;-))

Cron.hourly komut dosyasındaki svnsync komutlarının tümü, SVN deposu için SSL sertifikasının kabul edilmesi gerektiğini bildiren bir mesajla başarısız olur (bu, kullanıcının SVN deposuna ilk kez eriştiğinde etkileşimli olarak aldığınız iletidir, ancak sertifika I kabul edilen mesaj tekrar gelmez).

Bana öyle geliyor ki betiğin kök crontab üzerinden çalıştırıldığından daha fazla cron.hourly çalıştırıldığında farklı bir kullanıcı ortamında yürütülüyor. Farkı açıklayan var mı?

GÜNCELLEME: Dağıtımımdan bahsetmeliydim, CentOS 5.1'de anacron kullanıyorum.

GÜNCELLEME 2: Şimdiye kadarki öneriler için teşekkürler; Bence bu bir Subversion sorusuna dönüşüyor. Her zaman ortamımı komut dosyalarıma yerleştirmeye çalışıyorum, ancak burada sorun, SVN'yi komut dosyamı çalıştırdığımda SSL sertifikasının kabul edilmesini isteyen ortamın içinde ne olduğundan (veya eksik olduğundan) emin değilim cron.hourly. Sanırım bu çalışma parçaları komut dosyası yürütülür yolu ile ilgili bir şey.


1
Dağıtım ve cron seçim paketinizi dahil etmek yararlı olacaktır.
Dan Carley

Yanıtlar:


4

Kabul edilen sertifikayı nerede bulacağını bildirmek için '--config-dir' seçeneğini kullanmak istersiniz (örneğin, varsayılan olarak ~ / .subversion).

Bununla birlikte, başka bir yerde önerildiği gibi, bunun yerine kancalar / taahhüt sonrası komut dosyasından svnsync çağırmaktan daha iyi olacağınızdan eminim . Sonra aynanız, ustanızın bir saat önce nerede olduğu ile senkronize olmak yerine her zaman senkronize olur.


16

Debian / Ubuntu sisteminde cron.daily | weekly | montly ana crontab'dan başlatılır.

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 )

Ayrıca, /etc/cron.d/ dosyasına bir crontab parçası yerleştirebileceğinizi de unutmayın.

Gördüğünüz gibi bu çevre hakkında özel bir şey yok. En azından Debian / Ubuntu'da her şey kök hesap olarak çalıştırılır.

Komut dosyasının en başında cron komut dosyaları yazdığımda her zaman PATH'ımı ve kullanacağım diğer ortam değişkenlerini ayarladım, böylece herhangi bir ortamda doğru çalışacağından emin olabilirim.


6

Sistem genelindeki normal bir crontab, belirli bir kullanıcının crontab'ıdır ve tarafından kullanılan kullanıcı adı alanına sahiptir /etc/crontab.

Komut dosyalarını /etc/cron.*(saatlik, günlük, haftalık, aylık) olarak kullanmak, rootkullanıcı için crontab'ı yapılandırmanın daha temiz ve daha kolay bir yoludur (ortak sözdizimi hatalarını önler) ve bu, run-partsbir dizinde komut dosyalarını veya programları çalıştıran işlemdir . Tüm bu kurallar hala varsayılan olarak sistem genelindeki crontab'da ( /etc/crontab) tanımlanmıştır, bu yüzden aynı şeydir.

Cron işleri tarafından işlendiğinde run-parts, hata ayıklamak daha kolaydır, çünkü hangi komut dosyalarının tam olarak çalıştırılacağını (henüz çalıştırmadan) test edebilirsiniz:

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

3

İlk vahşi tahminim HOME değişkeninizi kontrol etmek olacaktır.

Centos sistemimde, adam 5 crontab diyor ki:

Çeşitli ortam değişkenleri cron (8) arka plan programı tarafından otomatik olarak ayarlanır. SHELL, / bin / sh olarak ayarlanır ve LOGNAME ve HOME, crontab sahibinin / etc / passwd satırından ayarlanır.

Bu nedenle, aksi belirtmediyseniz, root'un crontab'ı HOME için / root kullanır. Ancak / etc / crontab'da (/etc/cron.hourly öğesinin çalışma parçaları aracılığıyla çalıştırıldığı yer), HOME öğesi / (ve SHELL / bin / bash yerine / bin / sh yerine) olarak ayarlanır.

Svnsync hakkında bilmiyorum, ama yıkım bir ˜ / .subversion / dizin kullanır, böylece HOME bağlı olabilir.


3

RHEL 5.1 sistemimde PATH ortam değişkeni / etc / crontab olarak ayarlandı. Tepedeki tüm bu şeyler, çevreye beslenen şeyler.

Cron'u yeniden başlatırsanız, ilk kez çalıştırıldığında ( /etc/crontabya da ise /var/spool/cron/$USER) / var / log / cron içinde not alır. Aksi takdirde sadece cron.hourly koştu

Crontab'ım şu şekilde ayarlandı:

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

Yapabileceğiniz şey, /etc/cron.hourly içine aşağıdaki gibi bir şey koymaktır:

env > /tmp/cron.env

Sonra dosya geldiğinde inceleyin ve ortamı doğru şekilde ayarlamak için betiğinizi değiştirin (mümkünse) veya crontab'ınızın arayacağı kısa bir sargı betiği yazın.


2

/var/log/messages (veya dağıtımınızın eşdeğeri) size hangi komutun ne zaman ve hangi kullanıcı olarak çalıştırıldığının ayrıntılarını söylemelidir.


2

Asla çevrede bir şey olduğunu varsaymayın. Daima savunmacı bir şekilde kodlayın. İstediğiniz ortamın ayarlanmasını istediğiniz bir dosya var. Kullanın.


2

Çok fazla taşınabilirlik değil, son kontrol ettiğimde (Debian'da), cron.hourly'e (ve diğerlerine) bir şeyler koymanız ve malzemelerinizle bir paket oluşturmak istiyorsanız doğrudan crontab'a yerleştirilmemeniz önerildi.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.