Управление службами с помощью SMF

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

Если при запуске службы выясняется, что не работают какие-то другие службы, от которых она зависит, то служба не запускается и переводится в состояние offline . Если ошибки возникают во время запуска службы, она переводится в состояние maintenance .

Если все службы, от которых данная служба зависит, запущены и при запуске самой службы не возникли ошибки, она считается нормально запущенной и отмечается как находящаяся в состоянии online .

Удовлетворены ли взаимосвязи службы, определяется типом взаимосвязи:

• require_all – считается удовлетворенной, когда все перечисленные службы запущены (находятся в состояниях online или degraded ) или все указанные файлы присутствуют.
• require_any – считается удовлетворенной, когда хотя бы одна из перечисленных служб запущена (находится в состояниях online или degraded ) или по крайней мере один из указанных файлов присутствует.
• optional_all – считается удовлетворенной, когда все перечисленные службы запущены (находятся в состояниях online или degraded ), или не могут быть запущены без вмешательства администратора (т.е. находятся в состояниях disabled , maintenance , offline ), или не существуют.
• exclude_all – считается удовлетворенной, когда все перечисленные службы запрещено запускать, либо они находятся в состоянии maintenance , либо все указанные службы или файлы отсутствуют.

Взаимосвязи также иногда называют "зависимостями" (от англ. "dependencies").

Каждая служба управляется с помощью службы запуска ( restarter'a – т.е. "пускателя"). У службы может быть своя собственная служба запуска. Кроме этого, есть общая служба запуска – svc.startd . В документации она называется master restarter .

Служба запуска выполняет свои функции, вызывая методы каждой службы, за которую она отвечает. Методы – это обычно скрипты, которым передаются параметры start , stop , refresh и т.п.

Для службы также определяется контракт – механизм в ядре, позволяющий службе запуска получать информацию о тех службах, за запуск которых она отвечает.

Под "запуском" мы понимаем не только запуск служб при старте системы, но и перезапуск в случае аварийного завершения.

Узнать, от каких служб и файлов зависит служба, какая программа является ее службой запуска, а также изменить описание взаимосвязей можно с помощью команд svcs и svccfg соответственно.

Каждая служба имеет свое объявление ( manifest ) – файл в формате XML, содержащий полное описание всех свойств службы или ее экземпляра. Объявления служб хранятся в каталоге /var/svc/manifest . Эти файлы не следует использовать для изменения свойств служб, так как для этого предназначены команды svccfg и inetadm . Файлы объявлений сами по себе не являются источником информации для служб SMF , так как источником является репозиторий. Для импорта информации из файлов объявлений в репозиторий надо дать команду svccfg import или подождать перезагрузки – при старте системы импорт произойдет автоматически.

Для изучения структуры файлов объявлений имеет смысл прочесть страницу системного руководства по service_bundle(4) .

С помощью команды svccfg export можно получить архивный файл в формате XML со всеми свойствами всех служб, за исключением непостоянных свойств типа текущего состояния службы.

Унаследованные от прежних версий системы сценарии (скрипты) запуска служб, расположенные в каталогах /etc/rc?.d , запускаются как часть соответствующего этапа работы системы:

Запущенные с помощью этих скриптов процессы показываются в выводе svcs как экземпляры служб, которые идентифицируются полным именем файла, породившего процесс и находящегося в состоянии legacyrun . Этими службами нельзя управлять с помощью svcadm и для них не производится перезапуск и подробная диагностика в случае сбоев.

Для получения всех запущенных служб следует дать команду

Если бы нам требовался список всех служб, включая запрещенные к запуску, следовало бы дать команду

При поиске служб, которые оказались в состоянии maintenance и которым требуется вмешательство администратора для возобновления нормальной работы, следует использовать

Для изменения состояния службы надо пользоваться svcadm , для изменения настроек служб – svccfg , для получения информации о свойствах служб – svcprop .

Рассмотрим настройку конкретных служб на примере настроек сетевого интерфейса в Solaris.

Как указывалось в "лекции 2" , при настройке сети в Solaris Express можно применять одну из трех схем – классическую, связанную с inetmenu и самую современную, основанную на NWAM (NetWork Auto Magic). Можно ожидать, что после тестирования в дистрибутивах Solaris Express эта функциональность будет интегрирована в Solaris 10 или следующую версию Solaris.

Посмотрим, какие службы связаны с сетью в нашей системе (мы используем Solaris Express, build 79a для этого эксперимента):

Мы получили список только тех служб, которые в настоящий момент запущены. Только одна из них имеет отношение к настройкам сетевого интерфейса – svc:/network/physical:nwam .

Изучим свойства этой службы:

С помощью svccfg мы можем изменить свойства службы, в том числе указать другие методы для запуска.

Предположим, что нам надо перейти от настроек сети с помощью NWAM к классическому методу, т.е. к статическим файлам настроек, описанным в "лекции 3" . Для этого следует запретить службу svc:/network/physical:nwam и разрешить классическую настройку. Прежде всего потребуется выяснить, как называется служба классической настройки:

Теперь запретим запуск nwam и разрешим запуск physical:default (используем сокращенные идентификаторы служб):

Теперь конфигурация сети считывается из файлов конфигурации.

Хотя администратор Solaris в состоянии сам указать, какие службы следует запускать при старте системы, в помощь ему созданы профили. После установки или обновления системы для того, чтобы определить, какие службы следует запускать по умолчанию, система обращается к профилю generic.xml , который является символической ссылкой на generic_limited_net.xml .

В более старых версиях Solaris 10 (до Solaris 10 update 3 включительно) запускались службы согласно профилю generic_open.xml ( generic.xml указывал на него).

По сути дела профиль – это файл XML , содержащий список служб, разрешенных к запуску. В каталоге /var/svc/profile есть несколько предустановленных профилей:

• /var/svc/profile/generic_open.xml – службы, стандартные для более ранних версий Solaris 10;
• /var/svc/profile/generic_limited_net.xml – стандартные службы, как и в generic_open.xml , но с запретом запускать сетевые службы, кроме network/ssh ;
• /var/svc/profile/ns_*.xml – профиль разрешает запуск служб, имеющих отношение к службе имен;
• /var/svc/profile/platform_*.xml – профиль служб, связанных с конкретной аппаратной платформой.

Если в каталоге /var/svc/profile при старте системы обнаруживается профиль с именем site.xml , то в качестве списка запускаемых по умолчанию служб используется он. Вы можете создать свой собственный site.xml для компьютеров вашей организации на основе файлов *.xml в этом каталоге.

Для каждого экземпляра каждой службы всегда существует несколько снимков его настроек, которые можно использовать для возврата к предыдущим настройкам, если нынешние оказались неверными. Всего определено пять снимков (табл. 13.1):

Для возврата к предыдущим настройкам следует применять команды svccfg (и ее подкоманды – listsnap , selectsnap и revertsnap ), а для того, чтобы измененные настройки вступили в силу – svcadm refresh .