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

Re: "Правильные" демоны - не демоны?



On Thu, 10 Sep 2009 02:26:43 +0400
Иван Лох <loh@1917.com> wrote:

> Во-первых, я не фанат upstart. Монстр еще тот. Но сейчас активное внедрение
> того, что называют "событийная" модель в ядро и юзерспейс -- факт. И это
> неизбежное следствие увеличение числа и номенклатуры "втыкабельных" железяк,
> с одной стороны, и увеличения числа состояний системы (standby, suspend, пропала
> сеть, поменялся тип подключения) с другой. 
> 
> System V Init в этой ситуации неадекватен. Он рассчитан на то, что
> инициализация это разовый, а не постоянный процесс. Это почти верно для
> сервера в датацентре, но абсолютно неверно сейчас для рабочей станции.

Эти слова подкрепляются каким-нибудь исследованием или выводы сделаны на
основе чтения аннотаций к network-manager и upstart?

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

Любопытно, почему же /etc/{suspend,resume}.d и
/etc/network/ip-{up,down}.d являются костылями?

> > 2. категорически не нравится то, что "разруливание" зависимостей и
> > определение циклов происходит не на этапе конфигурирования, а на этапе
> > выполнения. Лично я не хотел бы, чтобы в один прекрасный момент система
> > отказалась грузиться, ругнувшись на обнаруженные циклические
> > зависимости.
> 
> Так она и сейчас иногда отказывает грузиться без таймаута или Ctrl-C.

Значит надо этот тайамут добавить.
Я последний раз нажимал Ctrl-C при загрузке, когда неправильно
сконфигурил интерфейсы и мне лень было ждать, пока DHCP-запрос отвалится
по таймауту.

> > знает ли кто-нибудь, как поведёт себя upstart, если событие, на которое
> > "повешен" скрипт вообще не произойдёт и насколько это будет применимо в
> > перечисленных случаях (монтирование usb-дисков в fstab, монтирование nfs)?
> 
> Если не появилась сеть, то, очевидно, nfs не смонтируется. 

Это действительно очевидно. Интереснее другое: будет ли мне сообщено о
том, что он не смонтировался или это быдет тихо пропущено?

> > 2. тут ещё проще: один раз пишется скрипт вида update-init-sequence,
> > который будет считывать зависимости, проводить на полученном графе
> > топологическую сортировку и сохранять симлинки в нужном порядке. При
> > обнаружении цикла следует ругаться как можно громче, давая
> > администратору возможность разрулить зависимости именно сейчас, а не
> > через полгода, когда понадобится машину перезагрузить.
> 
> Цикл можно обнаружить в runtime. Мне кажется, что именно здесь серьезной
> проблемы нет.

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

> Зависимости как правило простые. Железные -- я бы сказал.
> А если проблема с циклическими зависимостями у железа -- это уже беда.
> Не зависимо от init.

Что-то я вообще не понял смысла этого абзаца.

> Проблемы мне кажется будут другие. Массовый старт сервисов (проверки
> дисков и т д) после краха нестабильной/греющейся системы, может запросто
> грохнуть ее еще раз, во-первых. И, хрен ты что увидишь на консоли, во-вторых.

Я говорил про штатную перезагрузку, а не про аварийную.

-- 
Alexander Galanin

Attachment: pgpVgcRuUG4sD.pgp
Description: PGP signature


Reply to: