Одно отличие / 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
для ключей, которые должны быть абсолютно случайными.
Здесь обсуждается конкретно мой набор инструментов 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/
.
service-status
. nosh Guide. service-show
. nosh Guide. nagios-check-service
". system-control
. nosh Guide. 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
svstat
. руководство daemontools-encore. §8. sv
. руководство runit. §8. perpstat
. руководство по perp. §8. s6-svstat
. руководство по s6. Программное обеспечение Skarnet.