công việc cron thỉnh thoảng không chạy

Tôi có một CentOS 6.6máy chủ với các gói sau được cài đặt:

crontabs-1.10-33.el6.noarch
cronie-1.4.4-12.el6.x86_64
cronie-anacron-1.4.4-12.el6.x86_64
kernel-2.6.32-504.3.3.el6.x86_64

Đôi khi, một trong những công việc sao lưu được lên lịch để chạy hàng ngày chỉ đơn giản là không chạy. Kịch bản thậm chí không được gọi theo /var/log/cron.log. Thật thú vị khi đề cập rằng các công việc khác được lên kế hoạch để chạy chính xác cùng một lúc chạy mà không có bất kỳ vấn đề.

Tôi không thể tái tạo vấn đề và không phát hiện ra bất kỳ mẫu nào trên đó. Nếu tôi không làm gì thì công việc sẽ chạy đúng vào ngày hôm sau như mong đợi.

crond chỉ đơn giản là bỏ qua chỉ một trong nhiều công việc được cho là chạy vào một thời điểm cụ thể. Điều này chỉ xảy ra lẻ tẻ.

Tôi đọc ở một vài nơi khác mọi người nói về việc thêm một dòng trống ở cuối crontabtập tin. Công việc đôi khi không chạy được thực sự là ở dòng cuối cùng của crontabtập tin của tôi . Tôi không thể tìm thấy bất kỳ xác nhận đây là một lỗi thực sự hoặc đã biết.

# tail -2 /var/spool/cron/postgres
*  * * * * OTHERJOB
0 21 * * * /pg_backup.sh

Đây là tất cả những gì tôi có trong tôi /var/log/cron.log

Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19394]: (root) CMD (OTHERJOB)
Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19418]: (postgres) CMD (/pg_backup.sh)
Mar 31 21:01:02 SERVERNAME [cron.info] CROND[20062]: (root) CMD (OTHERJOB)

Apr  1 21:00:02 SERVERNAME [cron.info] CROND[31349]: (root) CMD (OTHERJOB)
Apr  1 21:01:01 SERVERNAME [cron.info] CROND[32080]: (root) CMD (OTHERJOB)

Xem làm thế nào OTHERJOBluôn luôn chạy trong khi trên Apr 1 pg_backup.shthậm chí không được thực hiện.

Tôi đã thử khởi động lại crondnhưng điều này vẫn tiếp tục. Điều này đang ảnh hưởng đến nhiều máy chủ có cùng phiên bản HĐH, kernel và cronRPM.

Có một phiên bản mới hơn của cronie( 1.4.12), tuy nhiên việc nâng cấp nó không phải là một tùy chọn vì chúng tôi đã sử dụng phiên bản mới nhất có sẵn choCentos 6.6

Tôi đã trải qua các thay đổi cho tất cả các croniephiên bản sau của tôi ( 1.4.4) và dường như không có bất kỳ sửa chữa nào cho vấn đề cụ thể này. Cũng kiểm tra tất cả các tin nhắn cam kết .

— Luis
nguồn

Xử lý sự cố tốt. Tại sao không thử thêm một dòng noop cuối cùng ( echo >/dev/nullví dụ)?

— Belmin Fernandez

Có bất kỳ lệnh ném lỗi của bạn. nó có thể dừng kịch bản Tôi đã có kinh nghiệm tương tự với các tập lệnh init.d.

— hardik

Làm thế nào nhanh chóng mỗi công việc hoàn thành? Nếu công việc mà bạn bắt đầu mỗi phút chạy trong hai phút mỗi lần, thì đó có thể là một vấn đề. Nhưng nếu nó hoàn thành trong hai giây, thì đó có lẽ không phải là vấn đề.

— kasperd

Công việc chạy mỗi phút (OTHERJOB) hoàn thành trong vài giây. Nhưng đó không phải là vấn đề. Tôi chỉ thêm OtherJOB vào nhật ký ở trên để cho thấy crond đang chạy và OTHERJOB đã được xử lý chính xác trong khi pg_backup.sh đơn giản là không chạy.

— Luis

Kiểm tra /var/log/audit/audit.log.

— Michael Hampton

Câu trả lời:

Cron ban đầu yêu cầu mỗi mục nhập kết thúc bằng một dòng mới, vì vậy đôi khi bạn cần một dòng trống hoặc một cái gì đó ở cuối.

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Một số phiên bản đã sửa hoặc phát cảnh báo, ví dụ Ubuntu Maverik (10.10): crontab xem phần chẩn đoán ở phía dưới, trong đó nêu cảnh báo sẽ được ghi vào syslog.

DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline  character.
       If  the last entry in a crontab is missing a newline (ie, terminated by
       EOF), cron will consider the crontab (at  least  partially)  broken.  A
       warning will be written to syslog.

— Brian
nguồn

Đây là câu trả lời đầu tiên đi kèm với văn bản tìm kiếm cron error getpwname failedvì vậy tôi nghĩ rằng tôi sẽ đăng nguyên nhân của vấn đề của mình:

Tôi đã sử dụng / etc / crontab nhưng đã quên đặt người dùng trước lệnh.

I E,

*/5   *  *  *  * /bin/bash <filename>

Thay vì

 */5   *  *  *  * root /bin/bash <filename>

Nó đã cho cùng một lỗi, đi con số.

— Aaron R.
nguồn

chúng tôi sử dụng sssdđể xác thực từ xa. crondphải kiểm tra người dùng có sẵn trước khi chạy các công việc và nó thực hiện việc này cứ sau 60 giây. sssdmặc định client_idle_timeoutlà 60 giây. vì vậy chúng tôi đã có một điều kiện cuộc đua giữa sssdvàcrond

Chúng tôi chỉ đi đến tận cùng của vấn đề này bởi vì trên phiên bản 1.4.4-14crond bắt đầu dài dòng hơn một chút về một số lỗi.

* Thu Feb  5 12:00:00 2015 Tomáš Mráz <tmraz@redhat.com> - 1.4.4-14
- add log message when getpwnam fails

Sau khi cập nhật lên phiên bản đó, chúng tôi bắt đầu thấy lỗi bên dưới đồng thời một công việc sẽ không chạy:

[cron.err] crond[8654]: (user) ERROR (getpwnam() failed): Broken pipe

điều đó đã đưa chúng ta đến điều này: https://ormszilla.redhat.com/show_orms.cgi?id=1209600#c2

và cuối cùng là thế này: https://access.redhat.com/solutions/1125133

Vấn đề: sssd_bebị chấm dứt với SIGKILL do getpwnam () trả lại EPIPE (tức là đường ống bị hỏng) có thể khiến crond âm thầm bỏ qua các mục công việc cron.

Giải pháp gợi ý về liên kết trên là thêm dòng bên dưới vào /etc/sssd/sssd.conf:

client_idle_timeout = 75

Thay đổi ở trên đã khắc phục sự cố cho chúng tôi và cron không còn bỏ qua công việc.

— Luis
nguồn