Làm cách nào để kiểm soát tốc độ khởi động lại tự động của dịch vụ runit?


8

Tôi có dịch vụ runit này runlog/runcác kịch bản hoạt động đúng.

Khi nó xảy ra, bản thân dịch vụ có thể bị sập vì lý do bên ngoài và có thể không thể khởi động trong nhiều phút. Cách mặc định mà runit xử lý tình huống này là khởi động lại dịch vụ cứ sau vài giây. Làm thế nào để tôi thay đổi hành vi này?

Cái nhìn sâu sắc cuối cùng của tôi là thêm một checkkịch bản và thực hiện một số phép thuật ở đó, nhưng có vẻ phức tạp hơn nhiều so với nó. Có cách nào đơn giản hơn?

Câu trả lời:


3

Tôi không quen thuộc với cơ sở này, tuy nhiên, nếu nhiệm vụ của tôi là giải quyết vấn đề này và việc đọc một trang rất ngắn không cung cấp một nút đơn giản để điều chỉnh hành vi này, tôi sẽ làm như sau:

Hoặc mở rộng tập lệnh bắt đầu dịch vụ hiện có hoặc nếu điều đó cồng kềnh, hãy chèn tập lệnh bắt đầu mới vào chuỗi (lần lượt bắt đầu tập lệnh bắt đầu ban đầu). Thay vì bắt đầu dịch vụ ngay lập tức, tập lệnh bắt đầu mới sẽ kiểm tra xem lần bắt đầu cuối cùng có xảy ra gần đây không. Điều này có thể được thực hiện bằng cách kiểm tra một tập tin báo hiệu được tạo bởi lần bắt đầu trước. Nếu tệp không tồn tại, tập lệnh có thể tiếp tục và chạm vào tệp và bắt đầu dịch vụ. Nếu tệp tồn tại, tập lệnh sẽ kiểm tra xem tệp đã đủ cũ chưa. Nếu nó không đủ tuổi, nó sẽ đợi (ngủ) trong một vòng lặp cho đến khi tập tin đủ tuổi.

Một cái gì đó như thế này có thể hoạt động (đợi ít nhất 1 phút giữa khi khởi động lại):

#!/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...

Đó là một cách tiếp cận tốt. Ngay khi tôi kiểm tra nó, tôi sẽ viết kịch bản với bất kỳ sửa chữa cần thiết nào có thể.
jpbochi

8

Bạn nên hạn chế tốc độ khởi động lại trong ./finishtệp cho dịch vụ đó, được chạy khi chấm dứt bất thường. Các ./finishkịch bản sẽ nhận được mã trở về từ ./runvà từ đó bạn có thể xác định những việc cần làm, vv Đối với vấn đề đó, bạn nên có của bạn ./finishkịch bản la hét ầm ĩ về những thất bại và gửi thông báo và nhảy khắp nơi trên lửa ...


Cảm ơn đây là câu trả lời đúng nhưng thật không may, các lập trình viên hiện đại sử dụng python, ruby, v.v ... dường như luôn viết các ứng dụng không chú ý đến các tín hiệu unix và hoàn toàn không cung cấp mã thoát phù hợp.
figtrap

1
Tôi đoán mã lỗi được trả về là "unool"?
Avery Payne

có vẻ như nó Tôi nghĩ rằng đó là một bước lùi tuyệt vời, bản thân mình.
figtrap

1

Tôi thực sự không phải là một fan hâm mộ của quản lý quy trình dựa trên init (và về cơ bản runit là một thay thế init). Như bạn đang khám phá, khởi động lại các quy trình thất bại ngay khi chúng chết không phải là một chiến lược đặc biệt tốt. Tôi đã sử dụng init để khởi động lại monit, nhưng đó là tất cả. (có khả năng sát thủ OOM có thể giết chết monit).

Vì vậy, tôi khuyến khích bạn tìm kiếm một sự thay thế thay vì sửa chữa mọi thứ.

Monit khá cũ, nhưng nó hoạt động rất tốt và tôi không nhận ra bất cứ điều gì tốt hơn khi đi cùng. Nó có một tính năng tuyệt vời là không cần phải mua thêm bộ nhớ sau khi khởi động, vì vậy hãy đánh bại mọi thứ được viết bằng ngôn ngữ kịch bản. Điều cuối cùng bạn muốn là trình giám sát quy trình của bạn chết vì nó không thể có được bộ nhớ.


systemd, bao gồm trong EL7 và hầu hết các bản phân phối khác, có thể xử lý tình huống này và một loạt các tình huống tương tự với số lượng lớn các tùy chọn và chủ yếu làm cho các nhà quản lý quy trình như những lỗi thời này.
Michael Hampton

1
Có một số ít tình huống trong đó systemd có thể "quá lớn" đối với môi trường đích. Và phương pháp cũ "quản lý quy trình bằng cách khởi động lại cho đến khi chạy" hầu hết được thay thế bằng độ phân giải phụ thuộc thích hợp. Xem skarnet.org/software/s6-rcjjacky.com/anopa để biết ví dụ.
Avery Payne
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.