Bagaimana cara mengontrol tingkat restart otomatis dari layanan runit?


8

Saya memiliki layanan runit ini rundan log/runskrip berfungsi dengan baik.

Seperti yang terjadi, layanan itu sendiri dapat macet karena alasan eksternal dan mungkin tidak dapat memulai selama beberapa menit. Cara default yang runit menangani situasi ini adalah dengan me-restart layanan setiap beberapa detik. Bagaimana saya mengubah perilaku ini?

Wawasan terakhir saya adalah menambahkan checkskrip dan melakukan beberapa sihir di sana, tetapi tampaknya jauh lebih rumit dari yang seharusnya. Apakah ada cara yang lebih sederhana dan lebih baik?

Jawaban:


3

Namun, saya tidak terbiasa dengan fasilitas ini, jika itu adalah tugas saya untuk menyelesaikan masalah ini, dan pembacaan halaman manual yang sangat singkat tidak menawarkan tombol sederhana untuk menyesuaikan perilaku ini, saya akan melakukan hal berikut:

Baik memperpanjang skrip mulai layanan yang ada, atau jika rumit, masukkan skrip awal baru ke dalam rantai (yang pada gilirannya memulai skrip awal yang asli). Alih-alih memulai layanan segera, skrip start yang baru harus memeriksa apakah permulaan terakhir terjadi cukup baru. Ini dapat dilakukan dengan memeriksa file signaling yang dibuat oleh awal sebelumnya. Jika file tidak ada, skrip dapat melanjutkan dan menyentuh file dan memulai layanan. Jika file tersebut ada, skrip harus memeriksa apakah file tersebut cukup lama. Jika belum cukup umur, ia harus menunggu (tidur) dalam satu lingkaran sampai file menjadi cukup tua.

Sesuatu seperti ini mungkin bekerja (tunggu setidaknya 1 menit antara restart):

#!/bin/bash

SIGNALDIR=/tmp
SIGNALFILE=service.started

while /bin/true; do
        found=`find "${SIGNALDIR}" -maxdepth 1 -name "${SIGNALFILE}" -mmin -1 | wc -l`
        [ "${found}" -eq 0 ] && break
        echo "Waiting"
        sleep 10
done

touch "${SIGNALDIR}/${SIGNALFILE}"
original service start...

Itu pendekatan yang bagus. Segera setelah saya mengujinya, saya akan skrip dengan koreksi yang diperlukan.
jpbochi

8

Anda harus membatasi tingkat restart Anda dalam ./finishfile untuk layanan itu, yang dijalankan pada penghentian abnormal. The ./finishScript akan menerima kode kembali dari ./rundan dari sana Anda dapat menentukan apa yang harus dilakukan, dll Untuk itu, Anda harus memiliki Anda ./finishskrip berteriak keras tentang kegagalan dan mengirim pemberitahuan dan melompat di sekitar terbakar ...


Terima kasih ini adalah jawaban yang tepat tetapi sayangnya programmer modern menggunakan python, ruby, dll. Tampaknya selalu menulis aplikasi yang tidak memperhatikan sinyal unix dan tidak memberikan kode keluar yang tepat sama sekali.
figtrap

1
Kode kesalahan yang dikembalikan ternyata "tidak keren", saya kira?
Avery Payne

sepertinya begitu. Saya pikir ini langkah mundur yang bagus, saya sendiri.
figtrap

1

Saya benar-benar bukan penggemar manajemen proses berbasis init (dan runit pada dasarnya adalah pengganti init). Ketika Anda menemukan, memulai kembali yang gagal dari proses yang gagal segera setelah mereka mati bukanlah strategi yang sangat baik. Saya sudah menggunakan init untuk me-restart monit, tapi itu sudah cukup. (Pembunuh OOM berpotensi dapat membunuh monit).

Jadi, saya mendorong Anda untuk mencari pengganti daripada memperbaiki keadaan.

Monit sudah cukup tua, tetapi berhasil dengan baik, dan saya tidak menyadari adanya sesuatu yang lebih baik. Ini memiliki fitur yang bagus karena tidak perlu melakukan malloc lebih banyak memori setelah start-up, jadi hentakan apa pun yang ditulis dalam bahasa scripting. Hal terakhir yang Anda inginkan adalah monitor proses Anda mati karena tidak bisa mendapatkan memori.


systemd, termasuk dalam EL7 dan sebagian besar distribusi lainnya, secara asli dapat menangani situasi ini dan berbagai situasi serupa dengan sejumlah besar pilihan dan sebagian besar membuat manajer proses seperti ini menjadi usang.
Michael Hampton

1
Ada beberapa situasi kecil di mana systemd mungkin "terlalu besar" untuk lingkungan target. Dan metode lama "manajemen proses dengan memulai kembali hingga berjalan" sebagian besar telah digantikan oleh resolusi ketergantungan yang tepat. Lihat skarnet.org/software/s6-rc dan jjacky.com/anopa untuk contohnya.
Avery Payne
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.