Как определить, была ли служба завершена (не работает, но должна)?

Одно отличие / dev / random заключается в том, что он останавливает вывод после использования пула энтропии. попробуйте следующее:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/ dev / urandom , однако будет повторно использовать тот же пул для продолжения вывода. как показано здесь:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Когда вы пытаетесь подключиться к этим специальным устройствам, ваша подсказка может быть испорчена. Просто введите reset и введите, ваш терминал вернется в нормальное состояние)

Используйте ] / dev / urandom , когда вам просто нужно что-то заполнить постоянным потоком «случайных» битов. Используйте / dev / random для ключей, которые должны быть абсолютно случайными.

2
15.05.2016, 11:49
1 ответ

Здесь обсуждается конкретно мой набор инструментов nosh, но некоторые концепции применимы и к другим членам семейства daemontools.

Возможно, вы захотите сказать людям из Gentoo, что их статья Process Supervision на вики сильно устарела и неполна.

Статус службы для людей

Получение статуса службы в человекочитаемой форме, конечно, осуществляется с помощью команд svstat, s6-svstat, sv stat или perpstat.

В наборе инструментов nosh есть команда svstat (она же service-status). Она, как и другие инструменты семейства daemontools, должна быть направлена непосредственно на нужные каталоги пакета служб. Набор инструментов также предоставляет system-control status shim, который ищет каталоги пакета сервисов (в различных обычных местах) по простому имени сервиса/цели и вызывает service-status.

Команда service-status набора инструментов nosh может выводить однострочную человекочитаемую форму для каждого сервиса или многострочную человекочитаемую форму. Обе формы содержат текущее состояние службы: остановлен, запущен, запущен, работает или остановлен. В 1-строчной форме к строке добавляется примечание, если это состояние отличается от состояния включения/выключения (которое определяет, должна ли служба быть изначально включена или выключена при загрузке). В последних версиях для привлечения внимания к этому примечанию используется цвет.

Многострочная человекочитаемая форма всегда содержит явное состояние включения/выключения службы, а также некоторые другие вещи, такие как конец журнала службы (если она имеет обычный log/ с обычным main/ каталогом). Поэтому, как человек, вы просто читаете и сравниваете.

Но это человекочитаемая форма. На самом деле его сложно надежно разобрать. И это только с учетом 1-строчных форм человекочитаемого вывода.

Статус службы для программ

Одна из максим безопасности qmail, впервые сформулированная в 20-м веке, гласит, что разбор человекочитаемого материала для интерфейса между программами - плохая идея. Для реализации программы мониторинга (например, скрипта мониторинга) гораздо лучше использовать инструмент, использующий машиночитаемый интерфейс.

Одним из таких машиночитаемых интерфейсов является, конечно же, сам API управления сервисами. API управления/статуса (совместимый с daemontools-encore) был стабилен и известен в течение многих лет, и представляет собой просто FIFO и обычные файлы в файловой системе. Можно написать программные библиотеки, которые просматривают непосредственно supervise/ok и supervise/status файлы сервиса для получения статуса, и люди так и делали. Примеры см. в библиотеке supervise Питера Руибала и Андреса Х. Диаса для Python и библиотеке Node JavaScript компании Voxer.

Набор инструментов nosh также поставляется с командой svshow (она же service-show и аналогичной system-control show shim), которая явно выдает машиночитаемый вывод о состоянии сервиса в форматах Microsoft INI или JSON.

Интеграция в средства мониторинга сервера/центра обработки данных

Различные системы мониторинга знают о системе supervise/status Бернштейна daemontools, расширенной Гюнтером daemontools-encore и используемой в управлении сервисами nosh. Их можно использовать как есть.

Для большего удобства набор инструментов nosh поставляется с командой nagios-check-service, которая может быть использована непосредственно как подключаемый модуль Nagios. Она говорит на языке протокола подключаемого модуля Nagios, используя соответствующие статусы выхода и записывая соответствующие вещи в стандартный вывод/ошибку, и поэтому может быть вставлена непосредственно в определение команды в /etc/nagios/nrpe.d/.

Дальнейшее чтение

  • Джонатан де Бойн Поллард (2015). Семейство daemontools. Часто задаваемые ответы.
  • Возможно, немного устарел nosh Guide:
    • Джонатан де Бойн Поллард. service-status. nosh Guide.
    • Джонатан де Бойн Поллард. service-show. nosh Guide.
    • Джонатан де Бойн Поллард. "nagios-check-service". system-control. nosh Guide.
  • The up-to-дата nosh Guide доступен как пакет Debian/Ubuntu и пакет FreeBSD/PC-BSD/DragonFlyBSD/&c., а руководство доступно на вашей машине без необходимости подключения к Интернету через:
    • man service-status
    • man service-show
    • man nagios-check-service
    • xdg-open /usr/local/share/doc/nosh/service-status.html
    • xdg-open /usr/local/share/doc/nosh/service-show.html
    • xdg-open /usr/local/share/doc/nosh/system-control.html
  • Bruce Guenter. svstat. руководство daemontools-encore. §8.
  • Gerrit Pape. sv. руководство runit. §8.
  • Уэйн Маршалл (2013). perpstat. руководство по perp. §8.
  • Laurent Bercot. s6-svstat. руководство по s6. Программное обеспечение Skarnet.
1
27.01.2020, 21:59

Теги

Похожие вопросы