pekerjaan cron kadang tidak berjalan

Saya memiliki CentOS 6.6server dengan paket-paket berikut diinstal:

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

Terkadang, salah satu pekerjaan cadangan yang dijadwalkan untuk berjalan setiap hari tidak berjalan. Script bahkan tidak dipanggil sesuai dengan /var/log/cron.log. Menarik untuk menyebutkan bahwa pekerjaan lain dijadwalkan untuk berjalan tepat pada saat yang sama berjalan tanpa masalah.

Saya tidak dapat mereproduksi masalah dan belum menemukan pola apa pun padanya. Jika saya tidak melakukan apa-apa, maka pekerjaan berjalan dengan benar pada hari berikutnya seperti yang diharapkan.

crond hanya mengabaikan salah satu dari banyak pekerjaan yang seharusnya dijalankan pada waktu tertentu. Ini hanya terjadi secara sporadis.

Saya membaca di beberapa tempat orang-orang berbicara tentang menambahkan baris kosong di akhir crontabfile. Pekerjaan yang terkadang gagal dijalankan memang ada di baris terakhir crontabfile saya . Saya tidak dapat menemukan konfirmasi apa pun bahwa ini adalah bug yang nyata atau diketahui.

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

Ini semua yang saya miliki di blog saya /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)

Lihat bagaimana OTHERJOBselalu berjalan saat Apr 1 pg_backup.shtidak bahkan dieksekusi.

Saya sudah mencoba memulai kembali crondtetapi ini terus terjadi. Ini memengaruhi banyak server dengan versi OS, kernel, dan cronRPM yang sama.

Ada versi yang lebih baru dari cronie( 1.4.12), namun memutakhirkannya bukanlah pilihan karena kami sudah menggunakan versi terbaru yang tersedia untukCentos 6.6

Saya telah melalui changelog untuk semua cronieversi setelah versi saya ( 1.4.4) dan sepertinya belum ada perbaikan untuk masalah ini. Juga memeriksa semua pesan komit .

— Luis
sumber

Pemecahan masalah yang baik. Mengapa tidak mencoba menambahkan noop last line ( echo >/dev/nulluntuk misal)?

— Belmin Fernandez

Apakah ada kesalahan melempar perintah Anda. mungkin bisa menghentikan skrip. Saya memiliki pengalaman serupa dengan skrip init.d.

— hardik

Seberapa cepat masing-masing pekerjaan selesai? Jika pekerjaan yang Anda mulai setiap menit berjalan selama dua menit setiap kali, maka itu mungkin menjadi masalah. Tetapi jika itu selesai dalam dua detik, maka itu mungkin bukan masalah.

— kasperd

Pekerjaan yang berjalan setiap menit (OTHERJOB) selesai dalam beberapa detik. Tapi bukan itu masalahnya. Saya hanya menambahkan OTHERJOB ke log di atas untuk menunjukkan bahwa crond sedang berjalan dan OTHERJOB diproses dengan benar sementara pg_backup.sh tidak berjalan.

— Luis

Periksa /var/log/audit/audit.log.

— Michael Hampton

Jawaban:

Cron asli mengharuskan setiap entri diakhiri dengan baris baru jadi ya kadang-kadang Anda memang membutuhkan baris kosong atau sesuatu di bagian akhir.

   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)

Beberapa versi memilikinya tetap atau memancarkan peringatan misalnya Ubuntu Maverik (10.10): crontab lihat di bagian diagnostik di bagian bawah yang menyatakan peringatan akan ditulis ke 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
sumber

Ini adalah jawaban pertama yang muncul dengan teks pencarian cron error getpwname failedjadi saya pikir saya akan memposting penyebab masalah saya:

Saya menggunakan / etc / crontab tetapi lupa untuk menempatkan pengguna di depan perintah.

yaitu,

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

Dari pada

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

Itu memberi kesalahan yang sama, pergi angka.

— Aaron R.
sumber

kami gunakan sssduntuk autentikasi jarak jauh. crondharus memeriksa pengguna yang tersedia sebelum menjalankan pekerjaan dan melakukan ini setiap 60 detik. sssdstandarnya client_idle_timeoutadalah 60 detik. jadi kami memiliki kondisi balapan antara sssddancrond

Kami hanya sampai di bagian bawah masalah ini karena pada versi 1.4.4-14crond mulai menjadi sedikit lebih banyak tentang beberapa kesalahan.

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

Setelah memperbarui ke versi itu kami mulai melihat kesalahan di bawah pada saat yang sama pekerjaan tidak akan berjalan:

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

yang membawa kami ke ini: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

dan akhirnya ke ini: https://access.redhat.com/solutions/1125133

Masalah: sssd_bediakhiri dengan SIGKILL karena getpwnam () mengembalikan EPIPE (mis. Pipa yang rusak) dapat menyebabkan crond untuk secara diam-diam melewati entri pekerjaan cron.

Solusi yang disarankan pada tautan di atas adalah tambahkan baris di bawah ini ke /etc/sssd/sssd.conf:

client_idle_timeout = 75

Perubahan di atas telah memperbaiki masalah bagi kami dan cron tidak lagi melewatkan pekerjaan.

— Luis
sumber