[devel] q: installer: Killing all remaining processes (forever)

Evgeny Sinelnikov =?iso-8859-1?q?sin_=CE=C1_altlinux=2Eru?=
Ср Апр 16 01:39:20 MSD 2008


2008/4/16 Dmitry V. Levin <ldv на altlinux.org>:
> On Tue, Apr 15, 2008 at 09:42:02PM +0400, Evgeny Sinelnikov wrote:
>  > 2008/4/15 Dmitry V. Levin <ldv на altlinux.org>:
>  [...]
>
> > >  У меня был один простой аргумент: ECHILD не происходит.
>  > >  Я сделал коммит, который ждёт ECHILD:
>  > >  http://git.altlinux.org/people/ldv/packages/?p=installer.git;a=commitdiff;h=0.4-alt12-1-g713c354
>  > >  На практике (в 0.4-alt13) это приводит к таймауту после 20 секунд ожидания.
>  >
>  > Кроме того на практике (в 0.4-alt13) loop_change_fd() на 2.6.24 всё
>  > ещё виснет... Я полагаю, что это влияние оптимизации кода ядра....
>  > Процесс не весь загружен в память, а после переброски файлового
>  > дескриптора на файл с нулями грузить его уже неоткуда...
>
>  Это вполне вероятно, поэтому reexec, видимо, нужно вернуть.
>

Проверьте, тот вариант, который у меня сейчас реализва в alt13.eter1.
Его можно назвать тем, что вы имели в виду под возвращеннием reexec?
Там, при старте, делается попытка скопировать /sbin/init в /mnt/init и
стартануть уже с него. Если попытка удаётся, то повторное монтирование
уже не делается. Кроме того, переменная окружения NEED_CHANGE_FD
устанавливатеся равной 0, иначе 1. Также пробрасываются ещё две
переменных окружения IMAGE_LOOP_DEV и IMAGE_TMP_FILE.

Далее если переменная NEED_CHANGE_FD выставлена в 1 работает более
долгий вариант с переброской всего образа в память перед отключением.
При этом скрипт 00-remove-image.sh проверяет наличие симлинки
/mnt/altinst.img, указывающей на не удалённый altinst на винте. Этот
скрипт переносит образ в память, удаляя его на винте... В этом случае
loop_change_fd() (на 2.6.24) работает.

Если же NEED_CHANGE_FD выствлен в 0, то 00-remove-image.sh ничего не
делает, поскольку вместо создания симлинки на образ, как и раньше,
сразу же после переноса на винт, образ satge2 удаляется. В этом случае
логика с loop_change_fd() (на 2.6.24 в смысле) на пустой файл
срабатывает, поскольку сам init уже перенесён в память...

>
>  > По поводу же ожидания в 20 секунд... Совершенно непонятна логика...
>  > ведь чтобы дождаться ECHILD не стоит отрывать обработку SIGCHILD...
>
>  Логика такая: поскольку не все процессы после рассылки SIGKILL
>  завершаются, дожидаться появления ECHILD бесполезно.
>

Логика, как мне кажется, ошибочна... ECHILD приходит, когда последний
процесс умирает. Приход именно этого сигнала выдавал предупреждение,
когда не до конца ожидался момент умирания всех процессов перед
отмонтированием. По сути получается так, что при умирании последнего
процесса, цикл в обработчике сигнала вынужден получить такую ошибку.
Поэтому отключение обработчика сигнала перед циклом ожидания
неверно... Это же подтверждено не практике. В моём случае стоит
ожидание только по этому сигналу, иначе цикл в killall() у меня вообще
не завершится... Но он завершается, а следовательно ECHILD, как и
ожидается, приходит...

>
>  > Иначе оно и будет висеть те самые 20 секунд... Причём не совсем 20,
>  > ведь sleep() всё-таки прерывается несколько раз по сигналу SIGCHILD от
>  > тех самых процессов, которых стоит дождаться...
>
>  Реализация sleep() следит за этими прерываниями.
>

Хм... это как? Там ведь получается, что каждый долгий sleep()
прерывается сигналом, рисуя очередную точку... Это то самое число
долгих процессов, которых нужно дождатся... Этих процессов, как
показывает практика, в среднем от двух до пяти... В случае же, когда
SIGCHILD отключен... Эти процессы быстро проталкивают цикл на 2-5
секунд и мы получаем от 18 до 15 секунд задержки, о которых вы
говорите....

>
>  > Объединённый и исправленный вариант доступен здесь:
>  > http://git.etersoft.ru/people/sin/packages/installer.git/
>  >
>  > В этот релиз вошло изменение решающее проблему loop_change_fd() на
>  > 2.6.24 путём переброски /sbin/init в память на начальном этапе
>  > установки. Надеюсь, это окончательный вариант исправлений...
>
>  Не стоит на это надеяться. ;)
>

Я сегодня проверил installer-0.4-alt13... На 2.6.24 он висит...
Хотелось бы внести в него логику из installer-0.4-alt13.eter1
(корректное ожидание ECHILD, исправление loop_change_fd() для 2.6.24).

-- 
Sin (Sinelnikov Evgeny)


Подробная информация о списке рассылки Devel