AlteratorServices: различия между версиями

Материал из ALT Linux Wiki
м (переименовал Alterator/AlteratorServices в AlteratorServices)
 
(не показана 1 промежуточная версия этого же участника)
Строка 33: Строка 33:
write <- name, change_status ("start" / "stop"), chkconfig_status (#t/#f)
write <- name, change_status ("start" / "stop"), chkconfig_status (#t/#f)


{{Alterator-nav}}
{{Category navigation|title=Модули Alterator|category=Модули Alterator|sortkey={{SUBPAGENAME}}}}

Текущая версия от 21:00, 21 июля 2015

Freesource-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была перемещена с freesource.info.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.


устройство модуля alterator-services

Управляение следующими параметрами:

  • текущее состояние сервиса: включен, выключен, неизвестно, включить/выключить (/sbin/service <service> start/stop/status)
  • включение сервиса при запуске: показать состояние, включить/выключить (chkconfig <service> on/off)

С отдельными runlevel'ами решили не работать.

Проблемы:

  • Как искать сервисы? В /etc/rc.d/init.d иногда лежит всякая фигня (например /etc/rc.d/init.d/halt), для которой даже пытаться узнать статус не слишком полезно... Так что тупой поиск по директории плох. Строить список сервисов с помощью /sbin/chkconfig - -list тоже не слишком правильно, так как мы теряем сервисы, которые были удалены из chkconfig'a

Решение: мы работаем только с сервисами, которые можно добавить в chkconfig. Просматриваем директорию /etc/rc.d/init.d, для каждого сервиса проверяем, есть ли он в chkconfig. Если нет - пытаемся добавить и смотрим, что получилось. Если сервис добавился - выключаем его (чтоб состояние не изменилось) и добавляем в список.

  • Для каких runlevel'ов включать сервисы? Тут варианты такие:
    • включать только для текущего уровня. Минус такой - если пользователь не пользуется разными уровнями - то этот вариант ничем не лучше остальных, если пользуется - он сможет запутать систему очень странным образом, так что запутанность не будет показываться этим модулем.
    • включать для тех уровней, которые указаны в заголовке скрипта (делать chkconfig -reset). На первый взгляд решение кажется самым правильным (то, что например, dm хочет вставать в 5, но не в 3 уровень - это его личное дело, которое пропивано в его заголовке), однако для многих скриптов в заголовке стоит прочерк (вроде как "вообще не запускать" сервис) - такие скрипты вообще не смогут быть запущены.
    • включать для некоторого известного набора уровней (например 2345, как делается по умолчанию в chkconfig, если уровни не указывать). Кажется, самый хороший вариант. Правда при этом вообще теряется различие между разными runlevel'ами, но, кажется, это небольшое зло. Кстати, при этом запутается смысл в переключении runlevel'а 3/5 в alterator-X11. Там лучше либо непосредственно управлять chkconfig dm on/off, либо вообще не управлять этим...

Решение: chkconfig <service> on/off

Всякие мелочи:

  • Состояние "включать при запуске" показывается по текущему runlevel'у.
  • для определения текущего состояния: запустить /sbin/service <service>, разобрать полученную строчку вида "Usage: aaa {start|stop|status|reload}", если можно, получть status, привести его к виду "running/stopped/unknown"
  • из строчки usage также можно понимать, поддерживает ли сервис команды start/stop (параметр switchable)

Интерфейс бакэнда

list -> (("services/xinetd" name "xinetd" status "running")...) -- статус пока не выдаётся, т.к. очень медленно, а использовать удобно только в qt... list для не-корневого объекта-> список действий типа "start" "stop" "restart" c label-переводами, в соответствии с текущим состоянием. read -> ("services/xinetd" name "xinetd" status "running" switchable #t chkconfig_status #t description "text") write <- name, change_status ("start" / "stop"), chkconfig_status (#t/#f)