On Wed, 9 Sep 2009 11:32:06 +0400 Alexander GQ Gerasiov <gq@cs.msu.su> wrote: > Разработчики испугались и обещали сами исправиться: > http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html Что-то не нравится мне этот upstart, причём сразу по нескольким причинам: 1. подменяют простую и понятную последовательную инициализцию на нечто в лучшем случае асинхронное, в худшем --- многопоточное. И то и другое отлаживать не так просто. 2. категорически не нравится то, что "разруливание" зависимостей и определение циклов происходит не на этапе конфигурирования, а на этапе выполнения. Лично я не хотел бы, чтобы в один прекрасный момент система отказалась грузиться, ругнувшись на обнаруженные циклические зависимости. Глядя с моей колокольни, лучше было бы решать так: 1. Вставить в скрипты, которые зависят от асинхронно выполняющихся ядерных операций (определение дисков, поднятие сетевых интерфейсов) команду на ожидание их завершения (с таймаутом, разумеется). К слову, а знает ли кто-нибудь, как поведёт себя upstart, если событие, на которое "повешен" скрипт вообще не произойдёт и насколько это будет применимо в перечисленных случаях (монтирование usb-дисков в fstab, монтирование nfs)? 2. тут ещё проще: один раз пишется скрипт вида update-init-sequence, который будет считывать зависимости, проводить на полученном графе топологическую сортировку и сохранять симлинки в нужном порядке. При обнаружении цикла следует ругаться как можно громче, давая администратору возможность разрулить зависимости именно сейчас, а не через полгода, когда понадобится машину перезагрузить. Жду коментариев. Если меня сейчас знающие люди не разнесут в пух и прах, можно будет и реализацию набросать, и предложение о замене апстарта на меньшее зло вынести. -- Alexander Galanin
Attachment:
pgpSebyrGkEjS.pgp
Description: PGP signature