Простий спосіб перезавантаження збійних процесів?


10

Мені потрібно стежити за кількома процесами, що працюють на моєму веб-сервері. Чомусь лак в даний час ламається раз на день чи два. Я використовую monit, щоб нібито автоматично перезапустити лак, але він не працює. Ось мій запис monit.conf для лаку.

check process varnish with pidfile /var/run/varnish.pid
    start program = "/etc/init.d/varnish start" with timeout 60 seconds
    stop program = "/etc/init.d/varnish stop"
    if failed host <my server ip> port 80 protocol http
        and request "/blank.html" then restart
    if 3 restarts within 5 cycles then timeout
    group server

Файл журналу показує, що після того, як лак перестає працювати, спроба після цього перезапуститься, всі провалюються. Тоді з часом monit припиняє моніторинг лаку.

У когось є пропозиції, як я можу це виправити? Або ще краще, чи можете ви запропонувати інші прості способи автоматичного моніторингу та перезавантаження збійних процесів? Дякую!


я не можу вірити, наскільки важкими були такі речі в досистемні часи.
Fl0v0

Відповіді:


17

Я б заглянув у daemontools ( http://cr.yp.to/daemontools.html ).

Супервізор був побудований саме з цією метою - запускати процеси та спостерігати за ними, негайно перезавантажуючи їх, якщо вони коли-небудь припиняться.

Ви все ще можете використовувати monit, якщо вам потрібно зробити щось складніше, ніж просту перевірку "чи все ще запущена", і якщо процес потрібно перезапустити, то зробіть це через нагляд.


Я також використовую daemontools для моніторингу процесів нестабільних служб. Досить зручно, якби мені довелося сказати. :-)
edomaur


2

Ви можете використовувати сценарії обробника подій з Nagios, якщо у вас є це місце, щоб перезапустити служби.

Якщо для запуску лаку потрібен дозвіл кореня (сценарії init.d зазвичай роблять), змініть "/etc/init.d/varnish start" на "sudo /etc/init.d/varnish start". Але це, мабуть, буде недостатньо, оскільки ви, мабуть, не хочете надавати користувачам монітор, як загальні привілеї sudo nopasswd для всіх команд, а надання судо сценарію оболонки було б в основному так само погано. Отже, вам потрібно буде розібратися, яким командам у цьому сценарії init потрібен sudo, надати цим командам привілеї sudo у файлі / etc / sudoers для користувача monit і остаточно відредагувати цей скрипт init відповідно. Чи, можливо, замість усього цього лаку можна запустити некористувача?

Нарешті, я впевнений, що ви це знаєте, але я все одно це скажу. Ви чітко докладаєте багато зусиль для цього, я сподіваюся, що ви докладете максимум зусиль, щоб з'ясувати, чому лак виходить з ладу і насправді це виправити (або завадить розробників розібратися, чому) :-)

Оновлення:
це може бути не таким чистим, але простий спосіб зробити це як root, можливо, створити сценарій, який перевіряє, чи нормально цей процес, а якщо не запускається. Тоді просто запускайте цей сценарій кожні пару хвилин, як робота з кроном.


Спочатку я розглядав Нагіос, але хотів чогось маленького і простого для своїх цілей. І так, я переглядаю випуск лаку. Один із моїх серверів дуже довго працює стабільно, тому це обов'язково має відношення до мене. :(
Лін

1

Ще один чудовий метод, взятий із StackOverflow :

until myserver; do
    echo "Server 'myserver' crashed with exit code $?.  Respawning.." >&2
    sleep 1
done

Сюди можна додати кронтаб:

crontab -e

Потім додайте правило для запуску сценарію монітора:

@reboot /usr/local/bin/myservermonitor

Або додано як сценарій у /etc/init.d

Дивіться відповідь StackOverflow для детального пояснення, чому це хороший підхід.


0

Я також шукав найпростіший спосіб вирішити цю проблему. Найпростіший спосіб, який я міг знайти, - це просто додати Restart=allwaysвідповідний .serviceфайл у /etc/systemd/system/multi-user.target.wants/останньому рядку [service]тегу.

Після цього зробити sudo systemctl daemon-reloadпотім sudo systemctl restart service.serviceперезавантажити зміни.

Ви можете перевірити, перевіривши, чи працює служба:, systemctl status processnameперевірте позначку часу початку. Після цього зробіть ps -ef | grep servicenameрекламний процес вбивством із щойно знайденим ідентифікатором kill 1234. після цього зробіть systemctl status processnameще раз і перевірте, чи оновлена ​​часова мітка початку.

Він повинен працювати над:

  • Debian 7 та Debian 8
  • Ubuntu 15.04 і новіші
  • CentOS 7 і майбутнє
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.