[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.



30 августа 2016 г., 13:26 пользователь Victor Wagner
<vitus@wagner.pp.ru> написал:

>> > Для конкретного случая можно специфицировать некое подмножество
>> > этого протокола.
>> > Например, вызов с параметрами start/stop/restart.
>> Если этот вызов для админа, а не для загрузки - не вижу проблем.
>
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или

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

> системы инициализации. В смысле, если предоставишь исполняемый
> файл с вот таким интерфейсом - при вызове с параметром start делает то,
> stop се, depends это, то система инициализации этот файл подхватит и
> будет через него демоном управлять.
>
> А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> существующих декларативных конифгов и врапперы для прочих случаев,
> поддерживающие этот протокол.

Для sysvinit я подобное ещё представляю. С другими init могут быть проблемы.

>> > И еще нужен протокол для работы с зависимостями. Нечто аналогичное
>> > LSB comments, но только встроенное в стандартный юниксовый
>> > протокол.
>> Как вариант - проверка наличия работающих зависимостей.
>> Возможно, автозапуск при старте, но это может быть спорно.

> Вот по-моему главное - это способ рассказать системе инициализации чего
> нам нужно. А в каком порядке что из этого запускать - пусть сама
> разбирается. На то есть startpar, хотя я и считаю его лишней сущностью,
> вместо которой надо make использовать.

Хм... Сложный вопрос, так как у системы инициализации может просто не
быть такого интерфейса в удобном виде.
Просто набор сервисов, которые требуется запустить в любом порядке +
внутри запускаемого конфига сервиса - команда на запуск зависимостей
из других сервисов.
При этом оно _не_ совместимо с тем, что обычно лежит в /etc/init.d и
может не предоставлять совместимый интерфейс в данном каталоге, а если
и предоставляет, то не использует это внутри себя.

-- 
Stanislav

Reply to: