☰

Как отвечает за отображение `Запуск ... [ ok ]`

tag-icon • tag-icon linux daemon
Как отвечает за отображение `Запуск ... [ ok ]`

Когда я запускаю такую ​​услугу, как:

root@foo [~]# service foobar stop
Stopping Foobar:                                       [  OK  ]

Я вижу индикатор состояния: [ OK ]который отличается от того, который виден на /var/log/boot.log:

[  OK  ] Started LSB: disk temperature monitoring daemon.
...

Или даже отличается от:

* /proc is already mounted
* Caching service dependencies ...        [ ok ]

В этих трех примерах какой процесс отвечает за отображение и запуск демонов? Другими словами, какая библиотека используется для отображения [ OK ], [FAILED]?

решение1

При ручном вызове serviceзапускает скрипт в стиле SysV из /etc/init.d или /etc/rc.d, все выходные данные о состоянии зависятполностью по этому сценарию.

Правильно написанные скрипты init.d будут использовать библиотеку функций оболочки, предоставляемую дистрибутивом. Например, в Debian большинство скриптов будут загружать (источник) файл /lib/lsb/init-functionsи просто вызывать его предоставляемые функции следующим образом:

случай "$1" в
  начинать)
    log_daemon_msg"Начиная с $DESC" "$NAME"
    do_start
    случай "$?" в
        0|1)log_end_msg0 ;;
        2) log_end_msg 1 ;;
    есак
    ;;
  [...]
есак

Вотсписок стандартных функцийопределяется LSB. (Обратите внимание, что дистрибутивы могут предоставлятьдополнительныйфункции за пределами стандарта, как пример выше. Также обратите внимание, что например OpenRC или Arch Linuxне являютсяСовместимы с LSB и используют совершенно разные стили.)

На самом деле, некоторые дистрибутивы также предоставляют этот шаблонный код централизованно, и все, что остается скрипту init.d, — это реализовать do_start. (См. OpenRC Gentoo и Debian /lib/init/init-d-scriptв качестве примеров). Однако это не «стандартная» функция LSB — скрипты, пытающиеся быть совместимыми с LSB, все равно должны делать это вручную.

Примечание:Я подчеркиваю «правильно написанное», потому что на самом деле нет ничего, что могло бысиласкрипт init.d для использования этих функций, кроме человеческого контроля. Если скрипт хочет сообщить о состоянии через plain echo(или через, cowsayесли на то пошло), он всегда может это сделать. Это особенно проблема с коммерческим программным обеспечением, распространяемым вне обычных каналов: их вывод статусаникогдавыглядит вполне правильно (и, честно говоря, весь скрипт init.d никогда не ведет себя вполне правильно).

Между тем, когда скрипты SysV вызываются во времяпроцесс загрузки, результат еще больше зависит от дистрибутива — иногда вы увидите вывод непосредственно из самих скриптов, но иногда «главная» система инициализации будет предоставлять свой собственный вывод состояния для всех запускаемых ею служб.Пример:(Старые сценарии инициализации Arch Linux при запуске службы в фоновом режиме.)

Но ваш второй пример на самом деленетinit в стиле SysV – это systemd (который просто запускает «устаревший» скрипт init.d в вашем примере). Systemd – это полноценный менеджер служб, который использует конфигурации служб (не скрипты), и поэтомувсеВывод статуса загрузки/выключения предоставляется самой systemd. Это также применимо к большинству других "менеджеров служб", включая init-ng, SMF или Upstart.

решение2

Это происходит из-за зависимых от дистрибутива init-скриптов. Проверьте содержимое программы service, это, вероятно, какой-то скрипт оболочки, вызывающий базовые скрипты управления (SysV сейчас считаются устаревшими) или двоичные файлы (systemd — это выход). Это один из плюсов systemd — вы не получите ответов «это зависит».

Связанный контент