Sự khác biệt giữa việc sử dụng crontab và /etc/cron.hourly,daily,weekly

Tôi có một tập lệnh được lên lịch thực hiện sao lưu svnsync hàng giờ trong kho Subversion của chúng tôi. Tôi đã chạy nó từ một mục trong crontab gốc mà không gặp vấn đề gì, nhưng quyết định tôi muốn chạy nó từ /etc/cron.hour thay vào đó để có thêm khả năng hiển thị (và vì một trong những kỹ sư của chúng tôi đã vô tình xóa crontab vì nghĩ rằng "crontab -r "có nghĩa là" đọc crontab ;-))

Các lệnh svnsync trong tập lệnh cron.hourly đều thất bại với một thông báo nói rằng chứng chỉ SSL cho kho lưu trữ SVN cần được chấp nhận (đây là thông báo bạn nhận được tương tác lần đầu tiên khi người dùng truy cập vào kho SVN, nhưng một khi chứng chỉ tôi chấp nhận tin nhắn không xuất hiện trở lại).

Vì vậy, dường như tập lệnh đang được thực thi trong một môi trường người dùng khác khi chạy từ cron.hourly so với khi nó chạy qua root crontab. Bất cứ ai có thể giải thích sự khác biệt?

CẬP NHẬT: Đáng lẽ tôi nên đề cập đến bản phân phối của mình, tôi đang sử dụng anacron trên CentOS 5.1.

CẬP NHẬT 2: Cảm ơn những lời đề nghị cho đến nay; Tôi nghĩ rằng điều này đang biến thành một câu hỏi Subversion. Tôi luôn cố gắng gói gọn môi trường của mình vào các tập lệnh của mình, nhưng vấn đề ở đây là tôi không chắc nó là gì (hoặc thiếu) môi trường khiến SVN yêu cầu chứng nhận SSL được chấp nhận khi tôi chạy tập lệnh của mình cron.hourly. Tôi đoán đó là một cái gì đó để làm với cách mà kịch bản phần chạy được thực thi.

Bạn muốn sử dụng tùy chọn '--config-dir' để cho nó biết nơi tìm chứng chỉ được chấp nhận (ví dụ ~ / .subversion theo mặc định).

Điều đó nói rằng, tôi gần như chắc chắn rằng bạn nên gọi svnsync từ tập lệnh hook / post-commit thay vào đó, như được đề xuất ở nơi khác . Sau đó, gương của bạn luôn đồng bộ, thay vì đồng bộ với nơi chủ của bạn cách đây một giờ.

Trên hệ thống Debian / Ubuntu cron.d Daily | hàng tuần | montly được bắt đầu từ crontab chính.

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 )

Ngoài ra, hãy nhớ rằng bạn có thể đặt một đoạn crontab trong /etc/cron.d/

Như bạn có thể thấy không có gì đặc biệt về môi trường này. Ít nhất là trên Debian / Ubuntu, tất cả đều được chạy dưới dạng tài khoản root.

Khi tôi viết tập lệnh cron ở đầu tập lệnh, tôi luôn đặt PATH và các biến môi trường khác mà tôi sẽ sử dụng, vì vậy tôi có thể chắc chắn rằng nó sẽ hoạt động chính xác trong mọi môi trường.

Một crontab toàn hệ thống thông thường là một crontab cụ thể của người dùng và nó có trường tên người dùng, như được sử dụng bởi /etc/crontab.

Sử dụng tập lệnh trong /etc/cron.*(hàng giờ, hàng ngày, hàng tuần, hàng tháng) là cách dễ dàng và dễ dàng hơn (ngăn ngừa các lỗi cú pháp phổ biến) để định cấu hình crontab cho rootngười dùng và điều này được xử lý bằng cách run-partschạy các tập lệnh hoặc chương trình trong một thư mục. Tất cả các quy tắc này vẫn được xác định trong crontab trên toàn hệ thống theo mặc định ( /etc/crontab), vì vậy đó là điều tương tự.

Khi các công việc cron được xử lý bởi run-parts, việc gỡ lỗi sẽ dễ dàng hơn, vì bạn có thể chỉ cần kiểm tra tập lệnh nào sẽ được chạy chính xác (mà không chạy chúng) bằng cách:

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

Dự đoán hoang dã đầu tiên của tôi sẽ được kiểm tra biến HOME của bạn.

Trên hệ thống Centos của tôi, người đàn ông 5 crontab nói:

Một số biến môi trường được thiết lập tự động bởi trình nền cron (8). SHELL được đặt thành / bin / sh và LOGNAME và HOME được đặt từ dòng / etc / passwd của chủ sở hữu crontab.

Vì vậy, nếu bạn không chỉ định khác, crontab của root sẽ sử dụng / root cho HOME. Nhưng trong / etc / crontab (là nơi /etc/cron.hourly được chạy từ, thông qua các phần chạy), HOME được đặt thành / (và SHELL thành / bin / bash thay vì / bin / sh).

Tôi không biết về svnsync, nhưng subversion không sử dụng thư mục ˜ / .subversion /, do đó có thể phụ thuộc vào HOME.

Trên hệ thống RHEL 5.1 của tôi, biến môi trường PATH được đặt từ / etc / crontab. Tất cả những thứ ở phía trên là những thứ được đưa vào môi trường.

Nếu bạn khởi động lại cron, thì lần đầu tiên nó chạy (nếu từ /etc/crontabhoặc /var/spool/cron/$USER), nó sẽ ghi chú trong / var / log / cron. Nếu không, nó sẽ chỉ lưu ý rằng cron.hourly chạy

Crontab của tôi được đặt thành như sau:

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

Những gì bạn có thể làm là đặt một cái gì đó như sau vào /etc/cron.hourly:

env > /tmp/cron.env

Sau đó kiểm tra tệp khi nó xuất hiện và sửa đổi tập lệnh của bạn (nếu bạn có thể) để đặt môi trường chính xác hoặc viết tập lệnh trình bao bọc ngắn mà crontab của bạn sẽ gọi.

/var/log/messages (hoặc tương đương với bản phân phối của bạn) sẽ cho bạn biết chi tiết cụ thể về lệnh nào được chạy khi nào và như người dùng nào.

Đừng bao giờ cho rằng có bất cứ điều gì trong môi trường. Luôn luôn mã phòng thủ. Bạn có toàn bộ tập tin để đặt bất cứ môi trường nào thiết lập công cụ bạn muốn vào đó. Sử dụng nó.

Không có gì khác về tính di động, lần trước tôi đã kiểm tra (trong Debian), bạn nên đặt nội dung vào cron.hourly (và những người khác) và không trực tiếp vào crontab nếu bạn muốn tạo gói bằng công cụ của mình.