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

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

[Michael Shigorin]

	Здравствуйте.
Это мне второй раз показалось или текущие installer 
с installer-desktop из 4.0/branch подвисают после вывода
надписи "Killing all remaining processes" (которую бы тоже
недурно облагородить -- вроде ж было как-то иначе уже)?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Wed, Apr 02, 2008 at 09:59:20PM +0400, Evgeny Sinelnikov wrote:
> > Это мне второй раз показалось или текущие installer
> > с installer-desktop из 4.0/branch подвисают после вывода
> > надписи "Killing all remaining processes" (которую бы тоже
> > недурно облагородить -- вроде ж было как-то иначе уже)?
> Совершенно верно, причём проблема довольно занятная (скорее
> всего из непонятных ядерных глюков, как в quake3 на наших
> 2.6.18 ядрах - #14027).

С этим самым ядром на этом самом тазике (и в том самом qemu на
другом тазике) не так давно не глючило.

Можно, конечно, взять installer из бранча или покататься...

> Как раз сейчас пытаюсь понять причину... Проблема в
> loop_change_fd() вызываемой из init в stage2 из пакета
> installer-stage2. Причём не совсем понятно зачем вообще это
> нужно.

Чтоб работал многодисковый инсталер.

> Тем не менее, если этот вызов убрать, оно всё равно падает, но
> уже после sysreboot()... Падает оно вроде всегда в Kernel panic
> - not syncing: Attempted to kill init!

У меня до того не доходило.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Sergey Bolshakov]

>>>>> "Michael" == Michael Shigorin <mike-nVB1ZwtFQf3sG83rWm+8vg@public.gmane.org> writes:

 > On Wed, Apr 02, 2008 at 09:59:20PM +0400, Evgeny Sinelnikov wrote:
 >> > Это мне второй раз показалось или текущие installer
 >> > с installer-desktop из 4.0/branch подвисают после вывода
 >> > надписи "Killing all remaining processes" (которую бы тоже
 >> > недурно облагородить -- вроде ж было как-то иначе уже)?
 >> Совершенно верно, причём проблема довольно занятная (скорее
 >> всего из непонятных ядерных глюков, как в quake3 на наших
 >> 2.6.18 ядрах - #14027).

 > С этим самым ядром на этом самом тазике (и в том самом qemu на
 > другом тазике) не так давно не глючило.

 > Можно, конечно, взять installer из бранча или покататься...

 >> Как раз сейчас пытаюсь понять причину... Проблема в
 >> loop_change_fd() вызываемой из init в stage2 из пакета
 >> installer-stage2. Причём не совсем понятно зачем вообще это
 >> нужно.

 > Чтоб работал многодисковый инсталер.

 >> Тем не менее, если этот вызов убрать, оно всё равно падает, но
 >> уже после sysreboot()... Падает оно вроде всегда в Kernel panic
 >> - not syncing: Attempted to kill init!

 > У меня до того не доходило.

Убийство init'а я наблюдал.

-- 

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

[Stanislav Ievlev]

Один раз наблюдался такой эффект когда Антон добавил в PATH к installer /sbin или /usr/sbin 
... но больше такого не наблюдалось.

On Wed, Apr 02, 2008 at 08:08:45PM +0300, Michael Shigorin wrote:
> 	Здравствуйте.
> Это мне второй раз показалось или текущие installer 
> с installer-desktop из 4.0/branch подвисают после вывода
> надписи "Killing all remaining processes" (которую бы тоже
> недурно облагородить -- вроде ж было как-то иначе уже)?
> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Stanislav Ievlev]

On Wed, Apr 02, 2008 at 09:59:20PM +0400, Evgeny Sinelnikov wrote:
> Здравствуйте,
> 
> 2008/4/2 Michael Shigorin <mike@osdn.org.ua>:
> 
> >        Здравствуйте.
> > Это мне второй раз показалось или текущие installer
> > с installer-desktop из 4.0/branch подвисают после вывода
> > надписи "Killing all remaining processes" (которую бы тоже
> > недурно облагородить -- вроде ж было как-то иначе уже)?
> >
> 
> Совершенно верно, причём проблема довольно занятная (скорее всего из
> непонятных ядерных глюков, как в quake3 на наших 2.6.18 ядрах - #14027). Как
> раз сейчас пытаюсь понять причину... Проблема в loop_change_fd() вызываемой
> из init в stage2 из пакета installer-stage2. Причём не совсем понятно зачем
> вообще это нужно. Тем не менее, если этот вызов убрать, оно всё равно
> падает, но уже после sysreboot()... Падает оно вроде всегда в
> Kernel panic - not syncing: Attempted to kill init!
loop_change_fd нужен для того чтобы дали отмонтировать /mnt/destination ...
Причём иногда это по неведомым мне причинам всё-равно не спасает ... ядро как-то себя не очень адекватно ведёт.

Если это очень хорошо воспроизводится на какой-нибудь машине, то было бы
очень здорово, если бы имеющие её не поленились вставить побольше отладки в install2-init.

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

[Michael Shigorin]

On Thu, Apr 03, 2008 at 10:22:23AM +0400, Stanislav Ievlev wrote:
> Если это очень хорошо воспроизводится на какой-нибудь машине,
> то было бы очень здорово, если бы имеющие её не поленились
> вставить побольше отладки в install2-init.

Выложить installer.iso, который в qemu воспроизводится?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Anton V. Boyarshinov]

> Это мне второй раз показалось или текущие installer 
> с installer-desktop из 4.0/branch подвисают после вывода
Скажем так. Я такое видел 1 раз на физической машине и несколько раз в qemu. И много-много раз НЕ видел.

АНтон

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

[Anton V. Boyarshinov]

On Thu, 3 Apr 2008 10:19:29 +0400 Stanislav Ievlev
 wrote:

> Один раз наблюдался такой эффект когда Антон добавил в PATH к installer /sbin или /usr/sbin 
> ... но больше такого не наблюдалось.
Но тот пакет был экспериментальным и ни в один дистрибутив или репозитоий не попал.

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

[Stanislav Ievlev]

On Thu, Apr 03, 2008 at 02:47:05PM +0400, Anton V. Boyarshinov wrote:
> > Это мне второй раз показалось или текущие installer 
> > с installer-desktop из 4.0/branch подвисают после вывода
> Скажем так. Я такое видел 1 раз на физической машине и несколько раз в qemu. И много-много раз НЕ видел.
Похоже что в qemu это хорошо воспроизводится ... надо мне как-нибудь
водрузить его на машину ;)
> 
> АНтон
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

[devel] qemu for testing

[Michael Shigorin]

On Thu, Apr 03, 2008 at 03:21:22PM +0400, Stanislav Ievlev wrote:
> > > Это мне второй раз показалось или текущие installer 
> > > с installer-desktop из 4.0/branch подвисают после вывода
> > Скажем так. Я такое видел 1 раз на физической машине и
> > несколько раз в qemu. И много-много раз НЕ видел.
> Похоже что в qemu это хорошо воспроизводится ... надо мне
> как-нибудь водрузить его на машину ;)

Дык а чего тут водружать -- apt-get install qemu и нужный
kernel-modules-kqemu, делаешь образ и пущаешь с ним:

qemu-img create qemu.img 10G
qemu -hda qemu.img -cdrom installer.iso -boot d

(PXE тоже умеет вроде)

PS: кажется, сейчас kqemu подгружается udev(?), а на первый раз
руками его modprobe'ни.

PPS: по идее, у тебя и qemu-kvm должен заработать -- он заметно
шустрее, чем с kqemu (что в свою очередь заметно быстрее "чистой"
эмуляции).  Если что, спроси led@.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] qemu for testing

[Led]

Thursday, 03 April 2008 14:26:58 Michael Shigorin написав:
> On Thu, Apr 03, 2008 at 03:21:22PM +0400, Stanislav Ievlev wrote:
> > > > Это мне второй раз показалось или текущие installer
> > > > с installer-desktop из 4.0/branch подвисают после вывода
> > >
> > > Скажем так. Я такое видел 1 раз на физической машине и
> > > несколько раз в qemu. И много-много раз НЕ видел.
> >
> > Похоже что в qemu это хорошо воспроизводится ... надо мне
> > как-нибудь водрузить его на машину ;)
>
> Дык а чего тут водружать -- apt-get install qemu и нужный
> kernel-modules-kqemu, делаешь образ и пущаешь с ним:
>
> qemu-img create qemu.img 10G
> qemu -hda qemu.img -cdrom installer.iso -boot d
>
> (PXE тоже умеет вроде)
>
> PS: кажется, сейчас kqemu подгружается udev(?),

Каким образом? При обнаружении какого физического устройства?:)

> а на первый раз 
> руками его modprobe'ни.

service kqemu
Майк, не путай людей:)

> PPS: по идее, у тебя и qemu-kvm должен заработать -- он заметно
> шустрее, чем с kqemu (что в свою очередь заметно быстрее "чистой"
> эмуляции).  Если что, спроси led@.

а вот здесь действительно нужен
modprobe kvm-(amd|intel)

-- 
Led

[devel] [JT] Re: qemu for testing

[Michael Shigorin]

On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
> > PS: кажется, сейчас kqemu подгружается udev(?),
> Каким образом? При обнаружении какого физического устройства?:)

Собственно, написал после

home:~> grep qemu /etc/modules
#kqemu

> > а на первый раз руками его modprobe'ни.
> service kqemu
> Майк, не путай людей:)

Ааааа. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] Re: qemu for testing

[Anton Farygin]

Michael Shigorin пишет:
> On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
>>> PS: кажется, сейчас kqemu подгружается udev(?),
>> Каким образом? При обнаружении какого физического устройства?:)
> 
> Собственно, написал после
> 
> home:~> grep qemu /etc/modules
> #kqemu

Только у меня что-то на нём вешается syslinux (на qemu-kvm). Может опции 
какие надо дать ?

Re: [devel] [JT] Re: qemu for testing

[Led]

В сообщении от Thursday 03 April 2008 14:50:43 Anton Farygin написал(а):
> Michael Shigorin пишет:
> > On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
> >>> PS: кажется, сейчас kqemu подгружается udev(?),
> >>
> >> Каким образом? При обнаружении какого физического устройства?:)
> >
> > Собственно, написал после
> >
> > home:~> grep qemu /etc/modules
> > #kqemu
>
> Только у меня что-то на нём вешается syslinux (на qemu-kvm). Может опции
> какие надо дать ?

Что значит "вешается syslinux"? LiveCD я разные пробовал - грузятся и 
работают, WinXP тоже работает... 


-- 
Led

Re: [devel] [JT] Re: qemu for testing

[Anton Farygin]

Led пишет:
> В сообщении от Thursday 03 April 2008 14:50:43 Anton Farygin написал(а):
>> Michael Shigorin пишет:
>>> On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
>>>>> PS: кажется, сейчас kqemu подгружается udev(?),
>>>> Каким образом? При обнаружении какого физического устройства?:)
>>> Собственно, написал после
>>>
>>> home:~> grep qemu /etc/modules
>>> #kqemu
>> Только у меня что-то на нём вешается syslinux (на qemu-kvm). Может опции
>> какие надо дать ?
> 
> Что значит "вешается syslinux"? LiveCD я разные пробовал - грузятся и 
> работают, WinXP тоже работает... 

Висит на старте...

Говорят, что это может зависить от CPU.

У меня Core2Duo.

Re: [devel] [JT] Re: qemu for testing

[Led]

Thursday, 03 April 2008 21:33:50 Anton Farygin написав:
> Led пишет:
> > В сообщении от Thursday 03 April 2008 14:50:43 Anton Farygin написал(а):
> >> Michael Shigorin пишет:
> >>> On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
> >>>>> PS: кажется, сейчас kqemu подгружается udev(?),
> >>>>
> >>>> Каким образом? При обнаружении какого физического устройства?:)
> >>>
> >>> Собственно, написал после
> >>>
> >>> home:~> grep qemu /etc/modules
> >>> #kqemu
> >>
> >> Только у меня что-то на нём вешается syslinux (на qemu-kvm). Может опции
> >> какие надо дать ?
> >
> > Что значит "вешается syslinux"? LiveCD я разные пробовал - грузятся и
> > работают, WinXP тоже работает...
>
> Висит на старте...
>
> Говорят, что это может зависить от CPU.
>
> У меня Core2Duo.

А ядро какое? kvm.ko и kvm-intel.ko откуда? я не сомневаюсь, что эти модули 
загружены конечно же и в логах / на 12-й консоли ничего подозритеьного при их 
загрузке?

-- 
Led

Re: [devel] [JT] Re: qemu for testing

[Damir Shayhutdinov]

>  Висит на старте...
>
>  Говорят, что это может зависить от CPU.
>
>  У меня Core2Duo.

http://kvm.qumranet.com/kvmwiki/Intel_Real_Mode_Emulation_Problems

Re: [devel] [JT] Re: qemu for testing

[Anton Farygin]

Led пишет:
> Thursday, 03 April 2008 21:33:50 Anton Farygin написав:
>> Led пишет:
>>> В сообщении от Thursday 03 April 2008 14:50:43 Anton Farygin написал(а):
>>>> Michael Shigorin пишет:
>>>>> On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
>>>>>>> PS: кажется, сейчас kqemu подгружается udev(?),
>>>>>> Каким образом? При обнаружении какого физического устройства?:)
>>>>> Собственно, написал после
>>>>>
>>>>> home:~> grep qemu /etc/modules
>>>>> #kqemu
>>>> Только у меня что-то на нём вешается syslinux (на qemu-kvm). Может опции
>>>> какие надо дать ?
>>> Что значит "вешается syslinux"? LiveCD я разные пробовал - грузятся и
>>> работают, WinXP тоже работает...
>> Висит на старте...
>>
>> Говорят, что это может зависить от CPU.
>>
>> У меня Core2Duo.
> 
> А ядро какое? kvm.ko и kvm-intel.ko откуда? я не сомневаюсь, что эти модули 
> загружены конечно же и в логах / на 12-й консоли ничего подозритеьного при их 
> загрузке?
> 

std-def, модули оттуда. Модули загружаются без ругани.

Re: [devel] [JT] Re: qemu for testing

[Anton Farygin]

Damir Shayhutdinov пишет:
>>  Висит на старте...
>>
>>  Говорят, что это может зависить от CPU.
>>
>>  У меня Core2Duo.
> 
> http://kvm.qumranet.com/kvmwiki/Intel_Real_Mode_Emulation_Problems

Да, это оно.

Re: [devel] [JT] Re: qemu for testing

[Led]

Friday, 04 April 2008 03:35:21 Anton Farygin написав:
> Led пишет:
> > Thursday, 03 April 2008 21:33:50 Anton Farygin написав:
> >> Led пишет:
> >>> В сообщении от Thursday 03 April 2008 14:50:43 Anton Farygin написал(а):
> >>>> Michael Shigorin пишет:
> >>>>> On Thu, Apr 03, 2008 at 02:37:19PM +0300, Led wrote:
> >>>>>>> PS: кажется, сейчас kqemu подгружается udev(?),
> >>>>>>
> >>>>>> Каким образом? При обнаружении какого физического устройства?:)
> >>>>>
> >>>>> Собственно, написал после
> >>>>>
> >>>>> home:~> grep qemu /etc/modules
> >>>>> #kqemu
> >>>>
> >>>> Только у меня что-то на нём вешается syslinux (на qemu-kvm). Может
> >>>> опции какие надо дать ?
> >>>
> >>> Что значит "вешается syslinux"? LiveCD я разные пробовал - грузятся и
> >>> работают, WinXP тоже работает...
> >>
> >> Висит на старте...
> >>
> >> Говорят, что это может зависить от CPU.
> >>
> >> У меня Core2Duo.
> >
> > А ядро какое? kvm.ko и kvm-intel.ko откуда? я не сомневаюсь, что эти
> > модули загружены конечно же и в логах / на 12-й консоли ничего
> > подозритеьного при их загрузке?
>
> std-def, модули оттуда. Модули загружаются без ругани.

Про эти не знаю. Я пользуюсь последними с http://sf.net/projects/kvm/ - 
соответствующий kernel-source-kvm есть в Sisyphus.

-- 
Led

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

[Evgeny Sinelnikov]

Здравстсвуйте,

2008/4/3 Stanislav Ievlev <inger@altlinux.org>:
> On Wed, Apr 02, 2008 at 09:59:20PM +0400, Evgeny Sinelnikov wrote:
>
>
> > Здравствуйте,
>  >
>  > 2008/4/2 Michael Shigorin <mike@osdn.org.ua>:
>  >
>  > >        Здравствуйте.
>  > > Это мне второй раз показалось или текущие installer
>  > > с installer-desktop из 4.0/branch подвисают после вывода
>  > > надписи "Killing all remaining processes" (которую бы тоже
>  > > недурно облагородить -- вроде ж было как-то иначе уже)?
>  > >
>  >
>  > Совершенно верно, причём проблема довольно занятная (скорее всего из
>  > непонятных ядерных глюков, как в quake3 на наших 2.6.18 ядрах - #14027). Как
>  > раз сейчас пытаюсь понять причину... Проблема в loop_change_fd() вызываемой
>  > из init в stage2 из пакета installer-stage2. Причём не совсем понятно зачем
>  > вообще это нужно. Тем не менее, если этот вызов убрать, оно всё равно
>  > падает, но уже после sysreboot()... Падает оно вроде всегда в
>  > Kernel panic - not syncing: Attempted to kill init!
>  loop_change_fd нужен для того чтобы дали отмонтировать /mnt/destination ...
>  Причём иногда это по неведомым мне причинам всё-равно не спасает ... ядро как-то себя не очень адекватно ведёт.
>
>  Если это очень хорошо воспроизводится на какой-нибудь машине, то было бы
>  очень здорово, если бы имеющие её не поленились вставить побольше отладки в install2-init.
>

Не поленились :) Дело в общем-то оказалось давнее. Ошибок было две:
1) во время копирования образа в память он затирался и работал на
каком-то остаточном ходу... волшебная функция sparse в начальных
скриптах запуска stage2 делала своё грязное дело довольно давно...
из-за этого иногда (а у меня на тесте в VirtualBox постоянно) не
работал loop_change_fd()
2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
дожидался момента завершения и падал из-за чего появлялся:
Kernel panic - not syncing: Attempted to kill init!

Исправленный вариант installer можно найти здесь:
http://git.etersoft.ru/people/sin/packages/installer.git/

Единственное, что осталось непонятным - это отмонтирование
/mnt/destination, в котором оказываются занятыми /mnt/destination/dev
и, при наличии, /mnt/destination/home... Комментарий по поводу
MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
по этому поводу предложения?

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] q: installer: Killing all remaining processes (pure M40)

[Michael Shigorin]

On Thu, Apr 03, 2008 at 02:47:55PM +0400, Anton V. Boyarshinov wrote:
> > Один раз наблюдался такой эффект когда Антон добавил в PATH к
> > installer /sbin или /usr/sbin ... но больше такого не
> > наблюдалось.
> Но тот пакет был экспериментальным и ни в один дистрибутив или
> репозитоий не попал.

Тем не менее на installer cd, собранном исключительно на пакетной
базе 4.0/branch с installer-desktop-0.2-alt4, installer-0.4-alt8
это у меня стабильно ловится.

И ещё оттуда же (01-remove-installer-desktop-pkgs.sh):

alterator-autoinstall is needed by alterator-lilo-0.2-alt2.3

Если кому интересно, возьмите mkimage-profiles-desktop у меня
в git.alt и сделайте нечто вроде

autoconf
./configure --with-aptconf=/path/to/apt.conf.M40 --with-distro=desktop
make installer.cd

2 boyarsh: я там отлопатил старое в сторонку; все цели проверены
до порезки toplevel makefile в кусочки, после собрал/проверил
rescue.cd и installer.cd, УМВР.  Если будет время, глянь pls
краем глаза.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Fri, Apr 04, 2008 at 10:00:03PM +0400, Evgeny Sinelnikov wrote:
[...]
> Не поленились :)

Спасибо!

> Дело в общем-то оказалось давнее. Ошибок было две:
> 1) во время копирования образа в память он затирался и работал на
> каком-то остаточном ходу... волшебная функция sparse в начальных
> скриптах запуска stage2 делала своё грязное дело довольно давно...
> из-за этого иногда (а у меня на тесте в VirtualBox постоянно) не
> работал loop_change_fd()

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

> 2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
> дожидался момента завершения и падал из-за чего появлялся:
> Kernel panic - not syncing: Attempted to kill init!

А вот это совершенно верно, коммит
fe761e03fcc44afc58687810844a1efc1a013e82
исправляет сразу две ошибки.

> Исправленный вариант installer можно найти здесь:
> http://git.etersoft.ru/people/sin/packages/installer.git/
> 
> Единственное, что осталось непонятным - это отмонтирование
> /mnt/destination, в котором оказываются занятыми /mnt/destination/dev
> и, при наличии, /mnt/destination/home... Комментарий по поводу
> MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
> по этому поводу предложения?

Нет, MNT_DETACH был убран специально, иначе не все ресурсы оказываются
полностью отмонтированными: после "поверхностного" отмонтирования
расположенные глубже ресурсы оказываются недоступными для отмонтирования.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

2008/4/5 Dmitry V. Levin <ldv@altlinux.org>:
> On Fri, Apr 04, 2008 at 10:00:03PM +0400, Evgeny Sinelnikov wrote:
>  [...]
>  > Не поленились :)
>
>  Спасибо!
>

Пожалуйста  :)

>  > Дело в общем-то оказалось давнее. Ошибок было две:
>  > 1) во время копирования образа в память он затирался и работал на
>  > каком-то остаточном ходу... волшебная функция sparse в начальных
>  > скриптах запуска stage2 делала своё грязное дело довольно давно...
>  > из-за этого иногда (а у меня на тесте в VirtualBox постоянно) не
>  > работал loop_change_fd()
>
>  Это было сделано специально, чтобы сэкономить несколько десятков мегабайт
>  памяти.  По крайней мере, содержимое этого образа уже не должно быть нужно
>  ни одному процессу.  Хорошо бы в этом как следует разобраться, всё-таки
>  несколько десятков мегабайт памяти иногда кое-что значит.
>

Довольно-таки смутно....  Как можно сэкономить "несколько десятков
мегабайт памяти" путём затирания образа в памяти после его
копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
потом затираем последние как минимум 512 байт с помощью dd
if=/dev/zero of=/mnt/altinst skip=$size_of_image... После этого оно
иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
"/mnt/altinst"), если ядро память почистило для своих нужно...

>
>  > 2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
>  > дожидался момента завершения и падал из-за чего появлялся:
>  > Kernel panic - not syncing: Attempted to kill init!
>
>  А вот это совершенно верно, коммит
>  fe761e03fcc44afc58687810844a1efc1a013e82
>  исправляет сразу две ошибки.
>
>
>  > Исправленный вариант installer можно найти здесь:
>  > http://git.etersoft.ru/people/sin/packages/installer.git/
>  >
>  > Единственное, что осталось непонятным - это отмонтирование
>  > /mnt/destination, в котором оказываются занятыми /mnt/destination/dev
>  > и, при наличии, /mnt/destination/home... Комментарий по поводу
>  > MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
>  > по этому поводу предложения?
>
>  Нет, MNT_DETACH был убран специально, иначе не все ресурсы оказываются
>  полностью отмонтированными: после "поверхностного" отмонтирования
>  расположенные глубже ресурсы оказываются недоступными для отмонтирования.
>

Ну, тут всё вообще очень мутно.... Почему init, который init_stage2,
оказывается занял что-то /mnt/destination/dev?


-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]

On Sat, Apr 05, 2008 at 04:29:59AM +0400, Evgeny Sinelnikov wrote:
[...]
> >  > Дело в общем-то оказалось давнее. Ошибок было две:
> >  > 1) во время копирования образа в память он затирался и работал на
> >  > каком-то остаточном ходу... волшебная функция sparse в начальных
> >  > скриптах запуска stage2 делала своё грязное дело довольно давно...
> >  > из-за этого иногда (а у меня на тесте в VirtualBox постоянно) не
> >  > работал loop_change_fd()
> >
> >  Это было сделано специально, чтобы сэкономить несколько десятков мегабайт
> >  памяти.  По крайней мере, содержимое этого образа уже не должно быть нужно
> >  ни одному процессу.  Хорошо бы в этом как следует разобраться, всё-таки
> >  несколько десятков мегабайт памяти иногда кое-что значит.
> >
> 
> Довольно-таки смутно....  Как можно сэкономить "несколько десятков
> мегабайт памяти" путём затирания образа в памяти после его
> копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
> потом затираем последние как минимум 512 байт с помощью dd
> if=/dev/zero of=/mnt/altinst skip=$size_of_image...

Идея была в том, чтобы создать файл-дырку /mnt/altlinst в точности
того же размера, что и исходный файл /image/altinst.

> После этого оно
> иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
> "/mnt/altinst"), если ядро память почистило для своих нужно...

Непонятно, почему оно может падать, если, по идее, оно больше не должно
использоваться в тот момент, когда вызывается завершающий loop_change_fd.

> >  > 2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
> >  > дожидался момента завершения и падал из-за чего появлялся:
> >  > Kernel panic - not syncing: Attempted to kill init!
> >
> >  А вот это совершенно верно, коммит
> >  fe761e03fcc44afc58687810844a1efc1a013e82
> >  исправляет сразу две ошибки.
> >
> >  > Исправленный вариант installer можно найти здесь:
> >  > http://git.etersoft.ru/people/sin/packages/installer.git/
> >  >
> >  > Единственное, что осталось непонятным - это отмонтирование
> >  > /mnt/destination, в котором оказываются занятыми /mnt/destination/dev
> >  > и, при наличии, /mnt/destination/home... Комментарий по поводу
> >  > MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
> >  > по этому поводу предложения?
> >
> >  Нет, MNT_DETACH был убран специально, иначе не все ресурсы оказываются
> >  полностью отмонтированными: после "поверхностного" отмонтирования
> >  расположенные глубже ресурсы оказываются недоступными для отмонтирования.
> 
> Ну, тут всё вообще очень мутно.... Почему init, который init_stage2,
> оказывается занял что-то /mnt/destination/dev?

Кажется, это последствия работы evms.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

2008/4/5 Dmitry V. Levin <ldv@altlinux.org>:
> On Sat, Apr 05, 2008 at 04:29:59AM +0400, Evgeny Sinelnikov wrote:
>  [...]
>
> > >  > Дело в общем-то оказалось давнее. Ошибок было две:
>  > >  > 1) во время копирования образа в память он затирался и работал на
>  > >  > каком-то остаточном ходу.... волшебная функция sparse в начальных
>  > >  > скриптах запуска stage2 делала своё грязное дело довольно давно...
>  > >  > из-за этого иногда (а у меня на тесте в VirtualBox постоянно) не
>  > >  > работал loop_change_fd()
>  > >
>  > >  Это было сделано специально, чтобы сэкономить несколько десятков мегабайт
>  > >  памяти.  По крайней мере, содержимое этого образа уже не должно быть нужно
>  > >  ни одному процессу.  Хорошо бы в этом как следует разобраться, всё-таки
>  > >  несколько десятков мегабайт памяти иногда кое-что значит.
>  > >
>  >
>  > Довольно-таки смутно....  Как можно сэкономить "несколько десятков
>  > мегабайт памяти" путём затирания образа в памяти после его
>  > копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
>  > потом затираем последние как минимум 512 байт с помощью dd
>  > if=/dev/zero of=/mnt/altinst skip=$size_of_image...
>
Кстати, тут 's/skip/seek/'

>  Идея была в том, чтобы создать файл-дырку /mnt/altlinst в точности
>  того же размера, что и исходный файл /image/altinst.
>

Довольно-таки странно сначала копировать файл, а потом поверх него
делать файл дырку. Я предположил, что порядок должен быть обратным -
перед копирование создаётся файл дырка нужного размера, для гарантии
непонятно чего (места на рамдиске?).... Иначе мы получали losetup-move
на файл с только что обнулённым куском в конце. Причём, если везде по
коду указывается $fs/altinst, то этот самый создатель файла-дырки
использует /mnt/altlinst. Такое ощущение, что его просто оставили во
время ручного мёрджинга.

>
>  > После этого оно
>  > иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
>  > "/mnt/altinst"), если ядро память почистило для своих нужно...
>
>  Непонятно, почему оно может падать, если, по идее, оно больше не должно
>  использоваться в тот момент, когда вызывается завершающий loop_change_fd.
>

Ну, это вот кстати, довольно просто... Оно же в памяти остаётся, чтобы
уметь сменить диск и добавить другой, с новыми пакетами. И нужно на
протяжении всего времени работы в stage2. Когда же мы делаем
losetup-move на один и от же вроде файл, у которого затёрты последние
512 байт может произойти глюк... Ядро на такой покоцаной файловой
системе в памяти просто падает.

Кстати, доводы относительно loop_change_fd() в многодисковой
установке, на последнем этапе работы установщика в stage2 несколько
меня смущают. Это могло быть сделано для корректного eject, но его не
делают... Может добавим?

>
>  > >  > 2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
>  > >  > дожидался момента завершения и падал из-за чего появлялся:
>  > >  > Kernel panic - not syncing: Attempted to kill init!
>  > >
>  > >  А вот это совершенно верно, коммит
>  > >  fe761e03fcc44afc58687810844a1efc1a013e82
>  > >  исправляет сразу две ошибки.
>  > >
>  > >  > Исправленный вариант installer можно найти здесь:
>  > >  > http://git.etersoft.ru/people/sin/packages/installer.git/
>  > >  >
>  > >  > Единственное, что осталось непонятным - это отмонтирование
>  > >  > /mnt/destination, в котором оказываются занятыми /mnt/destination/dev
>  > >  > и, при наличии, /mnt/destination/home... Комментарий по поводу
>  > >  > MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
>  > >  > по этому поводу предложения?
>  > >
>  > >  Нет, MNT_DETACH был убран специально, иначе не все ресурсы оказываются
>  > >  полностью отмонтированными: после "поверхностного" отмонтирования
>  > >  расположенные глубже ресурсы оказываются недоступными для отмонтирования.
>  >
>  > Ну, тут всё вообще очень мутно.... Почему init, который init_stage2,
>  > оказывается занял что-то /mnt/destination/dev?
>
>  Кажется, это последствия работы evms.
>

Ужасно.... Получается, что новые ФС на разделе сразу требуют поверки
сразу после установки...

-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 4022 bytes --]

On Sat, Apr 05, 2008 at 05:04:50AM +0400, Evgeny Sinelnikov wrote:
[...]
> Кстати, тут 's/skip/seek/'

Там и есть seek.

> >  Идея была в том, чтобы создать файл-дырку /mnt/altlinst в точности
> >  того же размера, что и исходный файл /image/altinst.
> 
> Довольно-таки странно сначала копировать файл, а потом поверх него
> делать файл дырку.

Разве поверх него?
Там копируется один файл, а потом создаётся другой файл-дырка.

> Я предположил, что порядок должен быть обратным -
> перед копирование создаётся файл дырка нужного размера, для гарантии
> непонятно чего (места на рамдиске?).... Иначе мы получали losetup-move
> на файл с только что обнулённым куском в конце. Причём, если везде по
> коду указывается $fs/altinst, то этот самый создатель файла-дырки
> использует /mnt/altlinst. Такое ощущение, что его просто оставили во
> время ручного мёрджинга.

Идея была именно сделать файл-дырку, на который потом в самом конце будет
loop_change_fd.  Именно это код make_sparse() и делает, если вызвать его
до создания файла /mnt/altinst.

> >  > После этого оно
> >  > иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
> >  > "/mnt/altinst"), если ядро память почистило для своих нужно...
> >
> >  Непонятно, почему оно может падать, если, по идее, оно больше не должно
> >  использоваться в тот момент, когда вызывается завершающий loop_change_fd.
> 
> Ну, это вот кстати, довольно просто... Оно же в памяти остаётся, чтобы
> уметь сменить диск и добавить другой, с новыми пакетами. И нужно на
> протяжении всего времени работы в stage2. Когда же мы делаем
> losetup-move на один и от же вроде файл, у которого затёрты последние
> 512 байт может произойти глюк... Ядро на такой покоцаной файловой
> системе в памяти просто падает.

Зануляется не тот файл, с которым работает процесс на stage2, а тот файл,
на который происходит loop_change_fd в самом конце install2-init.
В этот момент уже не должно остаться никаких процессов, использующих
файловую систему с этого образа -- их ведь уже убили с помощью
kill(-1, SIGKILL).

> Кстати, доводы относительно loop_change_fd() в многодисковой
> установке, на последнем этапе работы установщика в stage2 несколько
> меня смущают. Это могло быть сделано для корректного eject, но его не
> делают... Может добавим?

О чём речь?

> >  > >  > 2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
> >  > >  > дожидался момента завершения и падал из-за чего появлялся:
> >  > >  > Kernel panic - not syncing: Attempted to kill init!
> >  > >
> >  > >  А вот это совершенно верно, коммит
> >  > >  fe761e03fcc44afc58687810844a1efc1a013e82
> >  > >  исправляет сразу две ошибки.
> >  > >
> >  > >  > Исправленный вариант installer можно найти здесь:
> >  > >  > http://git.etersoft.ru/people/sin/packages/installer.git/
> >  > >  >
> >  > >  > Единственное, что осталось непонятным - это отмонтирование
> >  > >  > /mnt/destination, в котором оказываются занятыми /mnt/destination/dev
> >  > >  > и, при наличии, /mnt/destination/home... Комментарий по поводу
> >  > >  > MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
> >  > >  > по этому поводу предложения?
> >  > >
> >  > >  Нет, MNT_DETACH был убран специально, иначе не все ресурсы оказываются
> >  > >  полностью отмонтированными: после "поверхностного" отмонтирования
> >  > >  расположенные глубже ресурсы оказываются недоступными для отмонтирования.
> >  >
> >  > Ну, тут всё вообще очень мутно.... Почему init, который init_stage2,
> >  > оказывается занял что-то /mnt/destination/dev?
> >
> >  Кажется, это последствия работы evms.
> 
> Ужасно.... Получается, что новые ФС на разделе сразу требуют поверки
> сразу после установки...

Вся эта морока с перетаскиванием init на tmpfs и была затеяна для того,
чтобы отмонтировать свежесозданные разделы.
Тот код, который вы сейчас видите в install2-init.c, это, наверное, самый
простой способ решить эту задачу.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Stanislav Ievlev]

On Sat, Apr 05, 2008 at 05:04:50AM +0400, Evgeny Sinelnikov wrote:
> >  > мегабайт памяти" путём затирания образа в памяти после его
> >  > копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
> >  > потом затираем последние как минимум 512 байт с помощью dd
> >  > if=/dev/zero of=/mnt/altinst skip=$size_of_image...
> >
> Кстати, тут 's/skip/seek/'
согласен.
> 
> >  Идея была в том, чтобы создать файл-дырку /mnt/altlinst в точности
> >  того же размера, что и исходный файл /image/altinst.
> Ну, это вот кстати, довольно просто... Оно же в памяти остаётся, чтобы
> уметь сменить диск и добавить другой, с новыми пакетами. И нужно на
> протяжении всего времени работы в stage2. Когда же мы делаем
> losetup-move на один и от же вроде файл, у которого затёрты последние
> 512 байт может произойти глюк... Ядро на такой покоцаной файловой
> системе в памяти просто падает.
init не должен упасть ибо он собран статически и в момент вытаскивания
стула из-под себя висит в пямяти.

> 
> Кстати, доводы относительно loop_change_fd() в многодисковой
> установке, на последнем этапе работы установщика в stage2 несколько
> меня смущают. Это могло быть сделано для корректного eject, но его не
> делают... Может добавим?
Как сказал уже Дима, эта пляска не для eject ( с ним видимо отдельная
проблема), а для того чтобы отпустить /mnt/destination.
Мы перепробовали массу вариантов, чтобы отпустить его (был занят из-за первоначального losetup-move), 
но по неизвестным нам причинам, работал только этот хак с losetup-move на tmpfs.

P.S. Исправления с SIGCHILD приложу.

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

[Stanislav Ievlev]

On Sat, Apr 05, 2008 at 04:29:59AM +0400, Evgeny Sinelnikov wrote:
> Довольно-таки смутно....  Как можно сэкономить "несколько десятков
> мегабайт памяти" путём затирания образа в памяти после его
> копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
> потом затираем последние как минимум 512 байт с помощью dd
> if=/dev/zero of=/mnt/altinst skip=$size_of_image... После этого оно
> иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
> "/mnt/altinst"), если ядро память почистило для своих нужно...
> 
Не очень понял идею патча где сначала делается sparse_file, а потом уже
делается копирование altinst на диск.
Что изменилось после такой перестановки?

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

[Michael Shigorin]

On Mon, Apr 07, 2008 at 10:55:28AM +0400, Stanislav Ievlev wrote:
> P.S. Исправления с SIGCHILD приложу.

Просьба сообщить сюда, какая версия будет считаться стоящей
втягивания.  Пока попробую забрать ldv/installer.git.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Evgeny Sinelnikov]

2008/4/7 Stanislav Ievlev <inger@altlinux.org>:
> On Sat, Apr 05, 2008 at 04:29:59AM +0400, Evgeny Sinelnikov wrote:
>
> > Довольно-таки смутно....  Как можно сэкономить "несколько десятков
>  > мегабайт памяти" путём затирания образа в памяти после его
>  > копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
>  > потом затираем последние как минимум 512 байт с помощью dd
>  > if=/dev/zero of=/mnt/altinst skip=$size_of_image... После этого оно
>  > иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
>  > "/mnt/altinst"), если ядро память почистило для своих нужно...
>  >
>  Не очень понял идею патча где сначала делается sparse_file, а потом уже
>  делается копирование altinst на диск.
>  Что изменилось после такой перестановки?
>
Да, это результат вольной интерпретации того, как я понял глубокий
сакральный смысл make_sparse :) Тем не менее проблема оказалась в том,
что loop_change_fd() приводил к Segfault'у на тестах... Причины
довольно были туманны... Не у всех, но иногда так получается... Но на
виртуальной машине фиксированный образ у меня давал 100%
повторяемость... В итоге было предположено, что после kill(-1,
SIGKILL) не все процессы умирают... Нет, ну, они конечно умирают, но
не все сразу... Поэтому нужно дождаться сигнала ECHILD. Это решило
проблему отмонтирования для /mnt/destination/dev.

Проблема loop_change_fd() состоит в том, что то ли в виртуальных
машинах, то ли на 2.6.24, но грязный хак с перемонтированием корневой
системы на пустой файл приводит к зависанию системы... Обойти эту
ситуацию можно несколькими вариантами:
- путём уменьшения размера образа stage2 и удержания его в памяти
- копированием его на диск и удалением не сразу, а по окончанию
установки и переносу его в память на tmpfs, когда объём занимаемой
памяти уже не критичен
- восстановлением стабильной работы при выполнении loop_change_fd()

Я пока вижу вариант 2 вполне жизнеспособным....
Есть не нулевая вероятность, что патч исключающий рэйсы на killall()
может решить многие проблемы, в частности 3 вариант... Новый вариант
можно найти здесь:
http://git.etersoft.ru/people/sin/packages/installer.git/

-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Mon, Apr 07, 2008 at 08:38:41PM +0400, Evgeny Sinelnikov wrote:
[...]
> Да, это результат вольной интерпретации того, как я понял глубокий
> сакральный смысл make_sparse :) Тем не менее проблема оказалась в том,
> что loop_change_fd() приводил к Segfault'у на тестах... Причины
> довольно были туманны... Не у всех, но иногда так получается... Но на
> виртуальной машине фиксированный образ у меня давал 100%
> повторяемость... В итоге было предположено, что после kill(-1,
> SIGKILL) не все процессы умирают... Нет, ну, они конечно умирают, но
> не все сразу... Поэтому нужно дождаться сигнала ECHILD. Это решило
> проблему отмонтирования для /mnt/destination/dev.

К сожалению, коммит dee964d8b6da86bd575749d3631d41a013bbad7e создаёт
новый race.  Но идея безусловно правильная, надо будет реализовать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

2008/4/7 Dmitry V. Levin <ldv@altlinux.org>:
> On Mon, Apr 07, 2008 at 08:38:41PM +0400, Evgeny Sinelnikov wrote:
>  [...]
>
> > Да, это результат вольной интерпретации того, как я понял глубокий
>  > сакральный смысл make_sparse :) Тем не менее проблема оказалась в том,
>  > что loop_change_fd() приводил к Segfault'у на тестах... Причины
>  > довольно были туманны... Не у всех, но иногда так получается... Но на
>  > виртуальной машине фиксированный образ у меня давал 100%
>  > повторяемость... В итоге было предположено, что после kill(-1,
>  > SIGKILL) не все процессы умирают.... Нет, ну, они конечно умирают, но
>  > не все сразу... Поэтому нужно дождаться сигнала ECHILD. Это решило
>  > проблему отмонтирования для /mnt/destination/dev.
>
>  К сожалению, коммит dee964d8b6da86bd575749d3631d41a013bbad7e создаёт
>  новый race.  Но идея безусловно правильная, надо будет реализовать.
>

А можно по подробнее? В чём проявляется новый race? На вид
sig_atomic_t должен решать все проблемы...

-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

On Mon, Apr 07, 2008 at 08:58:35PM +0400, Evgeny Sinelnikov wrote:
> 2008/4/7 Dmitry V. Levin <ldv@altlinux.org>:
> > On Mon, Apr 07, 2008 at 08:38:41PM +0400, Evgeny Sinelnikov wrote:
> >  [...]
> >
> > > Да, это результат вольной интерпретации того, как я понял глубокий
> >  > сакральный смысл make_sparse :) Тем не менее проблема оказалась в том,
> >  > что loop_change_fd() приводил к Segfault'у на тестах... Причины
> >  > довольно были туманны... Не у всех, но иногда так получается... Но на
> >  > виртуальной машине фиксированный образ у меня давал 100%
> >  > повторяемость... В итоге было предположено, что после kill(-1,
> >  > SIGKILL) не все процессы умирают.... Нет, ну, они конечно умирают, но
> >  > не все сразу... Поэтому нужно дождаться сигнала ECHILD. Это решило
> >  > проблему отмонтирования для /mnt/destination/dev.
> >
> >  К сожалению, коммит dee964d8b6da86bd575749d3631d41a013bbad7e создаёт
> >  новый race.  Но идея безусловно правильная, надо будет реализовать.
> 
> А можно по подробнее? В чём проявляется новый race? На вид
> sig_atomic_t должен решать все проблемы...

while(!got_echild) pause();
между проверкой
(!got_echild)
и вызовом
pause();
может прийти сигнал, и тогда init зависнет.

К сожалению, понять, все ли процессы, которым выслали SIGKILL, могут быть
завершены, нереально.  Боюсь что sleep(1) будет проще.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Stanislav Ievlev]

Когда будете делать новые патчи - оповестите откуда брать.

Текущая версия по идее уже не выдаёт kernel panic, но неотмонтированный
/mnt/destination/dev всё ещё остаётся .

On Mon, Apr 07, 2008 at 09:07:02PM +0400, Dmitry V. Levin wrote:
> On Mon, Apr 07, 2008 at 08:58:35PM +0400, Evgeny Sinelnikov wrote:
> > 2008/4/7 Dmitry V. Levin <ldv@altlinux.org>:
> > > On Mon, Apr 07, 2008 at 08:38:41PM +0400, Evgeny Sinelnikov wrote:
> > >  [...]
> > >
> > > > Да, это результат вольной интерпретации того, как я понял глубокий
> > >  > сакральный смысл make_sparse :) Тем не менее проблема оказалась в том,
> > >  > что loop_change_fd() приводил к Segfault'у на тестах... Причины
> > >  > довольно были туманны... Не у всех, но иногда так получается... Но на
> > >  > виртуальной машине фиксированный образ у меня давал 100%
> > >  > повторяемость... В итоге было предположено, что после kill(-1,
> > >  > SIGKILL) не все процессы умирают.... Нет, ну, они конечно умирают, но
> > >  > не все сразу... Поэтому нужно дождаться сигнала ECHILD. Это решило
> > >  > проблему отмонтирования для /mnt/destination/dev.
> > >
> > >  К сожалению, коммит dee964d8b6da86bd575749d3631d41a013bbad7e создаёт
> > >  новый race.  Но идея безусловно правильная, надо будет реализовать.
> > 
> > А можно по подробнее? В чём проявляется новый race? На вид
> > sig_atomic_t должен решать все проблемы...
> 
> while(!got_echild) pause();
> между проверкой
> (!got_echild)
> и вызовом
> pause();
> может прийти сигнал, и тогда init зависнет.
> 
> К сожалению, понять, все ли процессы, которым выслали SIGKILL, могут быть
> завершены, нереально.  Боюсь что sleep(1) будет проще.
> 
> 
> -- 
> ldv



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Evgeny Sinelnikov]

Здравствуйте,

2008/4/8 Stanislav Ievlev <inger@altlinux.org>:
> Когда будете делать новые патчи - оповестите откуда брать.
>
>  Текущая версия по идее уже не выдаёт kernel panic, но неотмонтированный
>  /mnt/destination/dev всё ещё остаётся .
>
>
Проблема в том, что не корректно просто так добавлять sleep (1), нужно
ожидать сигнала ECHILD. После этого проблемы с /mnt/destination/dev
исчезают сами собой... Это раз.
Кроме того, я не знаю по какой причине, но у меня на всех тестах
loop_change_fd() на файл с нулями, даже после корректного ожидания
завершения всех процессов, виснет... Причём виснет как на реальных
машинах, так и на виртуальных... Вероятно разница в том, что у нас
разная пакетная база и ещё у меня ядро 2.6.24...  Я уже приводил ряд
вариантов исправления этого... Самый оптимальный из них, на мой
взгляд, состоит
в том, чтобы удалять altinst позже, причём перед этим перенося его на
tmpfs, и делая loop_change_fd() на нормальный файл. Это два.
Ряд исправлений к текущему варианту можно найти здесь:
http://git.etersoft.ru/people/sin/packages/installer.git/
В исправления вошли - корректное ожидание сигнала ECHILD после
killall(), корректная отработка postinstall и initinstall при
неудачном завершении отдельных скриптов, создание пустого /etc/mtab
для корректной отработки скриптов в postinstall, корректная отработка
зависания loop_change_fd() путём переноса оригинального образа в
память по окончанию установки.

-- 
Sin (Sinelnikov Evgeny)

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

[Michael Shigorin]

On Fri, Apr 11, 2008 at 05:18:23PM +0400, Evgeny Sinelnikov wrote:
> http://git.etersoft.ru/people/sin/packages/installer.git/
> В исправления вошли - корректное ожидание сигнала ECHILD после
> killall(), корректная отработка postinstall и initinstall при
> неудачном завершении отдельных скриптов, создание пустого
> /etc/mtab для корректной отработки скриптов в postinstall,
> корректная отработка зависания loop_change_fd() путём переноса
> оригинального образа в память по окончанию установки.

С 2.6.18-std-smp-alt12 залипания после killing processes нет,
файловые системы отчасти отмонтировались, но не совсем успешно
и при первой загрузке проверялись (/ при монтировании из
initramfs, /home -- уже из rc.sysinit):

http://fly.osdn.org.ua/~mike/tmp/postinstall.png
http://fly.osdn.org.ua/~mike/tmp/rootfs-recovery.png
http://fly.osdn.org.ua/~mike/tmp/home-recovery.png

PS http://fly.osdn.org.ua/~mike/tmp/gdm.png :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Stanislav Ievlev]

On Fri, Apr 11, 2008 at 05:18:23PM +0400, Evgeny Sinelnikov wrote:
> Здравствуйте,
> 
> 2008/4/8 Stanislav Ievlev <inger@altlinux.org>:
> > Когда будете делать новые патчи - оповестите откуда брать.
> >
> >  Текущая версия по идее уже не выдаёт kernel panic, но неотмонтированный
> >  /mnt/destination/dev всё ещё остаётся .
> >
> >
> Проблема в том, что не корректно просто так добавлять sleep (1), нужно
> ожидать сигнала ECHILD. После этого проблемы с /mnt/destination/dev
> исчезают сами собой... Это раз.
Это лучше с Дима скажет - у него были какие-то аргументы против ECHILD.

Что касается финального loop_change_fd, то сдаётся мне в свете
накопившегося опыта стоит попробовать следующее:
* copy+reexec init'a с tmpfs (тогда точно не будет никаких зависаний ибо
файл процесса уже будет вне опасности)
* по окончании работы pivot_root в tmpfs (откуда был запущен) далее kill и umount.
После второй операции возможно и повторный loop_change_fd не пригодится.

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

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

[Evgeny Sinelnikov]

2008/4/13 Michael Shigorin <mike@osdn.org.ua>:
> On Fri, Apr 11, 2008 at 05:18:23PM +0400, Evgeny Sinelnikov wrote:
>  > http://git.etersoft.ru/people/sin/packages/installer.git/
>  > В исправления вошли - корректное ожидание сигнала ECHILD после
>  > killall(), корректная отработка postinstall и initinstall при
>  > неудачном завершении отдельных скриптов, создание пустого
>  > /etc/mtab для корректной отработки скриптов в postinstall,
>  > корректная отработка зависания loop_change_fd() путём переноса
>  > оригинального образа в память по окончанию установки.
>
>  С 2.6.18-std-smp-alt12 залипания после killing processes нет,

У меня на 2.6.24 есть... Нужно как-то решить это вылечивамая проблема
на нём или нет... Вообще сам  это вариант с аодменой мне кажется
несколько жёстким... Не думаю, что ioctl() CHANGE_LOOP_FD на это
расчитан....

>  файловые системы отчасти отмонтировались, но не совсем успешно
>  и при первой загрузке проверялись (/ при монтировании из
>  initramfs, /home -- уже из rc.sysinit):

Это из-за того, что убиение процессов не доходит до конца...  В
installer-0.4-alt11 это уже внесено насколько я понял...

>
>  http://fly.osdn.org.ua/~mike/tmp/postinstall.png

Это как раз отсутствие ожидания убиения :)
Кстати, вот вгляните и скажите мне пожалуйста: "А почему не внесли
изменения на счёт корректной отработки postinstall и initinstall при
неудачном завершении отдельных скриптов?". Ведь после не отработавшего
удаления alterator-autoinstall (от него теперь зависит alterator-lilo)
остальные скрипты, включая eject, не отработали....

>  http://fly.osdn.org.ua/~mike/tmp/rootfs-recovery.png
>  http://fly.osdn.org.ua/~mike/tmp/home-recovery.png
>
Это очевидное следствие предыдущего... вы не использовали мой вариант
- вы мспользованли вариант из Сизифа...

>  PS http://fly.osdn.org.ua/~mike/tmp/gdm.png :-)
>

:)

-- 
Sin (Sinelnikov Evgeny)

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

[Evgeny Sinelnikov]

2008/4/13 Stanislav Ievlev <inger@altlinux.org>:
> On Fri, Apr 11, 2008 at 05:18:23PM +0400, Evgeny Sinelnikov wrote:
>
> > Здравствуйте,
>  >
>  > 2008/4/8 Stanislav Ievlev <inger@altlinux.org>:
>  > > Когда будете делать новые патчи - оповестите откуда брать.
>  > >
>  > >  Текущая версия по идее уже не выдаёт kernel panic, но неотмонтированный
>  > >  /mnt/destination/dev всё ещё остаётся .
>  > >
>  > >
>  > Проблема в том, что не корректно просто так добавлять sleep (1), нужно
>  > ожидать сигнала ECHILD. После этого проблемы с /mnt/destination/dev
>  > исчезают сами собой... Это раз.
>  Это лучше с Дима скажет - у него были какие-то аргументы против ECHILD.
>
>  Что касается финального loop_change_fd, то сдаётся мне в свете
>  накопившегося опыта стоит попробовать следующее:
>  * copy+reexec init'a с tmpfs (тогда точно не будет никаких зависаний ибо
>  файл процесса уже будет вне опасности)
>  * по окончании работы pivot_root в tmpfs (откуда был запущен) далее kill и umount.
>  После второй операции возможно и повторный loop_change_fd не пригодится.
>
>  Мы один раз уже пробовали эту схему, но тогда видать не дотумкали насчёт
>  ожидания убиения процессов, увидели что не получается отмонтирование и
>  отказались от неё. Стоит попробовать ещё разок.
>

Да, это интересная идея... Завтра проверю...


-- 
Sin (Sinelnikov Evgeny)

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

[Stanislav Ievlev]

On Mon, Apr 14, 2008 at 04:00:38AM +0400, Evgeny Sinelnikov wrote:
> >  Что касается финального loop_change_fd, то сдаётся мне в свете
> >  накопившегося опыта стоит попробовать следующее:
> >  * copy+reexec init'a с tmpfs (тогда точно не будет никаких зависаний ибо
> >  файл процесса уже будет вне опасности)
> >  * по окончании работы pivot_root в tmpfs (откуда был запущен) далее kill и umount.
> >  После второй операции возможно и повторный loop_change_fd не пригодится.
> >
> >  Мы один раз уже пробовали эту схему, но тогда видать не дотумкали насчёт
> >  ожидания убиения процессов, увидели что не получается отмонтирование и
> >  отказались от неё. Стоит попробовать ещё разок.
> >
> 
> Да, это интересная идея... Завтра проверю...
А я тогда подожду результатов ;)
зависание видимо было из-за того что несмотря на статичность файла init,
он был загружен при помощи mmap и не вся его часть попала с loop в память.

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

[Michael Shigorin]

On Mon, Apr 14, 2008 at 03:58:01AM +0400, Evgeny Sinelnikov wrote:
> Кстати, вот вгляните и скажите мне пожалуйста: "А почему не
> внесли изменения на счёт корректной отработки postinstall и
> initinstall при неудачном завершении отдельных скриптов?". Ведь
> после не отработавшего удаления alterator-autoinstall (от него
> теперь зависит alterator-lilo) остальные скрипты, включая
> eject, не отработали....

Думал, уже вешал такой баг -- оказывается, нет.  Повесите?
Действительно заколебало уже.

> >  http://fly.osdn.org.ua/~mike/tmp/rootfs-recovery.png
> >  http://fly.osdn.org.ua/~mike/tmp/home-recovery.png
> Это очевидное следствие предыдущего... вы не использовали мой
> вариант - вы мспользованли вариант из Сизифа...

Это как раз Ваш был, с сизифным на 2.6.18 трапаемся после 
killing processes, здесь же попытались размонтироваться:
http://fly.osdn.org.ua/~mike/tmp/postinstall.png

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Evgeny Sinelnikov]

Здравствуйте.

2008/4/14 Michael Shigorin <mike@osdn.org.ua>:
> On Mon, Apr 14, 2008 at 03:58:01AM +0400, Evgeny Sinelnikov wrote:
>  > Кстати, вот вгляните и скажите мне пожалуйста: "А почему не
>  > внесли изменения на счёт корректной отработки postinstall и
>  > initinstall при неудачном завершении отдельных скриптов?". Ведь
>  > после не отработавшего удаления alterator-autoinstall (от него
>  > теперь зависит alterator-lilo) остальные скрипты, включая
>  > eject, не отработали....
>
>  Думал, уже вешал такой баг -- оказывается, нет.  Повесите?
>  Действительно заколебало уже.
>

Это всё уже вошло в installer-0.4-alt12 (в смысле отваливания при
любой ошибке), насколько я понял, когда сегодня объеднялся с ним.
Причиной там является довольно специфичное поведение цикла while в
bash.

>
>  > >  http://fly.osdn.org.ua/~mike/tmp/rootfs-recovery.png
>  > >  http://fly.osdn.org.ua/~mike/tmp/home-recovery.png
>  > Это очевидное следствие предыдущего... вы не использовали мой
>  > вариант - вы мспользованли вариант из Сизифа...
>
>  Это как раз Ваш был, с сизифным на 2.6.18 трапаемся после
>  killing processes, здесь же попытались размонтироваться:
>
> http://fly.osdn.org.ua/~mike/tmp/postinstall.png
>

Странно... Моих вариантов было уже много... Последний так себя вести не может:
http://git.etersoft.ru/people/sin/packages/installer.git/

1) В нём есть post-скрипт remove-image.sh, на примере же его нет.
2) В нём ошибки в post-скриптах не приводят к падению, основного
скрипта postinstall.

Вероятно мы говорим уже про разные версии...

-- 
Sin (Sinelnikov Evgeny)

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

[Evgeny Sinelnikov]

2008/4/14 Stanislav Ievlev <inger@altlinux.org>:
> On Mon, Apr 14, 2008 at 04:00:38AM +0400, Evgeny Sinelnikov wrote:
>  > >  Что касается финального loop_change_fd, то сдаётся мне в свете
>  > >  накопившегося опыта стоит попробовать следующее:
>  > >  * copy+reexec init'a с tmpfs (тогда точно не будет никаких зависаний ибо
>  > >  файл процесса уже будет вне опасности)
>  > >  * по окончании работы pivot_root в tmpfs (откуда был запущен) далее kill и umount.
>  > >  После второй операции возможно и повторный loop_change_fd не пригодится.
>  > >
>  > >  Мы один раз уже пробовали эту схему, но тогда видать не дотумкали насчёт
>  > >  ожидания убиения процессов, увидели что не получается отмонтирование и
>  > >  отказались от неё. Стоит попробовать ещё разок.
>  > >
>  >
>  > Да, это интересная идея... Завтра проверю...
>  А я тогда подожду результатов ;)
>  зависание видимо было из-за того что несмотря на статичность файла init,
>  он был загружен при помощи mmap и не вся его часть попала с loop в память.
>

Что-то оно сегодня не всё успелось... я собрал, но не опробовал
вариант первичного перенесения init в tmpfs. По итоге стало ясно, что
вариант переносить init по завершении работы выглядит разумнее...


-- 
Sin (Sinelnikov Evgeny)

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

[Stanislav Ievlev]

On Tue, Apr 15, 2008 at 02:13:14AM +0400, Evgeny Sinelnikov wrote:
> 2008/4/14 Stanislav Ievlev <inger@altlinux.org>:
> > On Mon, Apr 14, 2008 at 04:00:38AM +0400, Evgeny Sinelnikov wrote:
> >  > >  Что касается финального loop_change_fd, то сдаётся мне в свете
> >  > >  накопившегося опыта стоит попробовать следующее:
> >  > >  * copy+reexec init'a с tmpfs (тогда точно не будет никаких зависаний ибо
> >  > >  файл процесса уже будет вне опасности)
> >  > >  * по окончании работы pivot_root в tmpfs (откуда был запущен) далее kill и umount.
> >  > >  После второй операции возможно и повторный loop_change_fd не пригодится.
> >  > >
> >  > >  Мы один раз уже пробовали эту схему, но тогда видать не дотумкали насчёт
> >  > >  ожидания убиения процессов, увидели что не получается отмонтирование и
> >  > >  отказались от неё. Стоит попробовать ещё разок.
> >  > >
> >  >
> >  > Да, это интересная идея... Завтра проверю...
> >  А я тогда подожду результатов ;)
> >  зависание видимо было из-за того что несмотря на статичность файла init,
> >  он был загружен при помощи mmap и не вся его часть попала с loop в память.
> >
> 
> Что-то оно сегодня не всё успелось... я собрал, но не опробовал
> вариант первичного перенесения init в tmpfs. По итоге стало ясно, что
> вариант переносить init по завершении работы выглядит разумнее...
А по мне так проще в начале, чтобы код менее
ветвистым был.
Так при повторном запуске половину программы придётся пропускать, а иначе только один вызов функции.

Кстати вариант с SIGCHILD стал заметно дольше ожидать киляния
процессов ... устанавливал только один раз, ожидание было порядка трёх
секунд, по началу даже подумал что опять зависло. 

Или надо это ускорять или делать рисование точек интенсивнее.

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

[Michael Shigorin]

On Tue, Apr 15, 2008 at 02:03:44AM +0400, Evgeny Sinelnikov wrote:
> Это всё уже вошло в installer-0.4-alt12

Стас, готовься делать бэкпорт на 4.0.  Вот зачем было устраивать
несовместимые изменения перед школьным выпуском? :)
 
> >  > >  http://fly.osdn.org.ua/~mike/tmp/rootfs-recovery.png
> >  > >  http://fly.osdn.org.ua/~mike/tmp/home-recovery.png
> >  > Это очевидное следствие предыдущего... вы не использовали
> >  > мой вариант - вы мспользованли вариант из Сизифа...
> >  Это как раз Ваш был, с сизифным на 2.6.18 трапаемся после
> >  killing processes, здесь же попытались размонтироваться:
> > http://fly.osdn.org.ua/~mike/tmp/postinstall.png
> Странно... Моих вариантов было уже много... Последний так себя
> вести не может:
> http://git.etersoft.ru/people/sin/packages/installer.git/

Постараюсь проверить.

> 1) В нём есть post-скрипт remove-image.sh, на примере же его нет.
> 2) В нём ошибки в post-скриптах не приводят к падению, основного
> скрипта postinstall.
> Вероятно мы говорим уже про разные версии...

Дык см. дату :-)  То был 0.4-alt9.eter1.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Tue, Apr 15, 2008 at 11:42:36AM +0400, Stanislav Ievlev wrote:
> On Tue, Apr 15, 2008 at 02:13:14AM +0400, Evgeny Sinelnikov wrote:
> > 2008/4/14 Stanislav Ievlev <inger@altlinux.org>:
> > > On Mon, Apr 14, 2008 at 04:00:38AM +0400, Evgeny Sinelnikov wrote:
> > >  > >  Что касается финального loop_change_fd, то сдаётся мне в свете
> > >  > >  накопившегося опыта стоит попробовать следующее:
> > >  > >  * copy+reexec init'a с tmpfs (тогда точно не будет никаких зависаний ибо
> > >  > >  файл процесса уже будет вне опасности)
> > >  > >  * по окончании работы pivot_root в tmpfs (откуда был запущен) далее kill и umount.
> > >  > >  После второй операции возможно и повторный loop_change_fd не пригодится.
> > >  > >
> > >  > >  Мы один раз уже пробовали эту схему, но тогда видать не дотумкали насчёт
> > >  > >  ожидания убиения процессов, увидели что не получается отмонтирование и
> > >  > >  отказались от неё. Стоит попробовать ещё разок.
> > >  >
> > >  > Да, это интересная идея... Завтра проверю...
> > >  А я тогда подожду результатов ;)
> > >  зависание видимо было из-за того что несмотря на статичность файла init,
> > >  он был загружен при помощи mmap и не вся его часть попала с loop в память.
> > 
> > Что-то оно сегодня не всё успелось... я собрал, но не опробовал
> > вариант первичного перенесения init в tmpfs. По итоге стало ясно, что
> > вариант переносить init по завершении работы выглядит разумнее...
> А по мне так проще в начале, чтобы код менее
> ветвистым был.
> Так при повторном запуске половину программы придётся пропускать, а иначе только один вызов функции.

А я бы сделал reexec после killall.

> Кстати вариант с SIGCHILD стал заметно дольше ожидать киляния
> процессов ... устанавливал только один раз, ожидание было порядка трёх
> секунд, по началу даже подумал что опять зависло. 

Там sleep(1)

> Или надо это ускорять или делать рисование точек интенсивнее.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

On Sun, Apr 13, 2008 at 01:54:05PM +0400, Stanislav Ievlev wrote:
> On Fri, Apr 11, 2008 at 05:18:23PM +0400, Evgeny Sinelnikov wrote:
> > Здравствуйте,
> > 
> > 2008/4/8 Stanislav Ievlev <inger@altlinux.org>:
> > > Когда будете делать новые патчи - оповестите откуда брать.
> > >
> > >  Текущая версия по идее уже не выдаёт kernel panic, но неотмонтированный
> > >  /mnt/destination/dev всё ещё остаётся .
> > >
> > >
> > Проблема в том, что не корректно просто так добавлять sleep (1), нужно
> > ожидать сигнала ECHILD. После этого проблемы с /mnt/destination/dev
> > исчезают сами собой... Это раз.
> Это лучше с Дима скажет - у него были какие-то аргументы против ECHILD.

У меня был один простой аргумент: ECHILD не происходит.
Я сделал коммит, который ждёт ECHILD:
http://git.altlinux.org/people/ldv/packages/?p=installer.git;a=commitdiff;h=0.4-alt12-1-g713c354
На практике (в 0.4-alt13) это приводит к таймауту после 20 секунд ожидания.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

Здравствуйте,

2008/4/15 Dmitry V. Levin <ldv@altlinux.org>:
> On Sun, Apr 13, 2008 at 01:54:05PM +0400, Stanislav Ievlev wrote:
>  > On Fri, Apr 11, 2008 at 05:18:23PM +0400, Evgeny Sinelnikov wrote:
>  > > Здравствуйте,
>  > >
>  > > 2008/4/8 Stanislav Ievlev <inger@altlinux.org>:
>  > > > Когда будете делать новые патчи - оповестите откуда брать.
>  > > >
>  > > >  Текущая версия по идее уже не выдаёт kernel panic, но неотмонтированный
>  > > >  /mnt/destination/dev всё ещё остаётся .
>  > > >
>  > > >
>  > > Проблема в том, что не корректно просто так добавлять sleep (1), нужно
>  > > ожидать сигнала ECHILD. После этого проблемы с /mnt/destination/dev
>  > > исчезают сами собой... Это раз.
>  > Это лучше с Дима скажет - у него были какие-то аргументы против ECHILD.
>
>  У меня был один простой аргумент: 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 всё
ещё виснет... Я полагаю, что это влияние оптимизации кода ядра....
Процесс не весь загружен в память, а после переброски файлового
дескриптора на файл с нулями грузить его уже неоткуда...

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

Объединённый и исправленный вариант доступен здесь:
http://git.etersoft.ru/people/sin/packages/installer.git/

В этот релиз вошло изменение решающее проблему loop_change_fd() на
2.6.24 путём переброски /sbin/init в память на начальном этапе
установки. Надеюсь, это окончательный вариант исправлений...

-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

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, видимо, нужно вернуть.

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

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

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

Реализация sleep() следит за этими прерываниями.

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

Не стоит на это надеяться. ;)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

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)

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

[Evgeny Sinelnikov]

2008/4/16 Evgeny Sinelnikov <sin@altlinux.ru>:
> 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 секунд ожидания.

[...]

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

Просмотрел текущие изменения по поводу "Reduce ECHILD wait timeout to
5 seconds" - 0706e8db880cc8a650fb0dda7427079a09a9eb11.
Думаю, что уменьшение времени здесь конечно помогает, но это опять
игра race conditions... На самом деле достаточно убрать
chld_handler(0); И время можно будет ставить сколь угодно долгим...


-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

On Wed, Apr 16, 2008 at 01:39:20AM +0400, Evgeny Sinelnikov wrote:
> 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 уже перенесён в память...

Я не понял, зачем было так сильно усложнять?
Если перед loop_change_fd просто скопировать содержимое /proc/self/exe
(а это статический ELF) в файл на tmpfs и запустить?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On Wed, Apr 16, 2008 at 01:39:20AM +0400, Evgeny Sinelnikov wrote:
> >  > Иначе оно и будет висеть те самые 20 секунд... Причём не совсем 20,
> >  > ведь sleep() всё-таки прерывается несколько раз по сигналу SIGCHILD от
> >  > тех самых процессов, которых стоит дождаться...
> >
> >  Реализация sleep() следит за этими прерываниями.
> >
> 
> Хм... это как? Там ведь получается, что каждый долгий sleep()
> прерывается сигналом, рисуя очередную точку... Это то самое число
> долгих процессов, которых нужно дождатся... Этих процессов, как
> показывает практика, в среднем от двух до пяти... В случае же, когда
> SIGCHILD отключен... Эти процессы быстро проталкивают цикл на 2-5
> секунд и мы получаем от 18 до 15 секунд задержки, о которых вы
> говорите....

Нет, sleep(3) не прерывается сигналом SIGCHLD.  Если сказано спать
1 секунду, то оно будет спать не менее 1 секунды.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On Wed, Apr 16, 2008 at 01:39:20AM +0400, Evgeny Sinelnikov wrote:
> >  Логика такая: поскольку не все процессы после рассылки SIGKILL
> >  завершаются, дожидаться появления ECHILD бесполезно.
> 
> Логика, как мне кажется, ошибочна... ECHILD приходит, когда последний
> процесс умирает.

Почему вы так решили?

"The waitpid() function shall fail if:
[ECHILD] The process specified by pid does not exist or is not a child of
the calling process, or the process group specified by pid does not exist
or does not have any member process that is a child of the calling
process."

Пример:

$ cat waitpid.c
#include <sys/wait.h>
int main(void)
{
	int status;
	waitpid(-1, &status, WNOHANG);
	waitpid(-1, &status, WNOHANG);
	return 0;
}

$ strace -qe waitpid ./waitpid
waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)

> Приход именно этого сигнала выдавал предупреждение,
> когда не до конца ожидался момент умирания всех процессов перед
> отмонтированием. По сути получается так, что при умирании последнего
> процесса, цикл в обработчике сигнала вынужден получить такую ошибку.
> Поэтому отключение обработчика сигнала перед циклом ожидания
> неверно...

Отключение обработчика сигнала?  Мы точно говорим про один и тот же код?

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

ECHILD у init произойдёт только в случае если в системе не останется
процессов, у которых ppid==1; такое может произойти, но может и не
произойти.  У нас на стенде init не получал ECHILD ни разу.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Wed, Apr 16, 2008 at 02:02:08AM +0400, Evgeny Sinelnikov wrote:
[...]
> Просмотрел текущие изменения по поводу "Reduce ECHILD wait timeout to
> 5 seconds" - 0706e8db880cc8a650fb0dda7427079a09a9eb11.
> Думаю, что уменьшение времени здесь конечно помогает, но это опять
> игра race conditions... На самом деле достаточно убрать
> chld_handler(0); И время можно будет ставить сколь угодно долгим...

Что такое chld_handler(0)?  Это прямой вызов обработчика сигнала SIGCHLD.
Если его убрать, то где гарантия того, что он будет вызван хотя бы один
раз?  Нам нужна такая гарантия для того, чтобы в случае, если все процессы
с ppid==1 завершились, флаг got_ECHILD был гарантированно установлен.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

2008/4/16 Dmitry V. Levin <ldv@altlinux.org>:
> On Wed, Apr 16, 2008 at 01:39:20AM +0400, Evgeny Sinelnikov wrote:
>
> > >  Логика такая: поскольку не все процессы после рассылки SIGKILL
>  > >  завершаются, дожидаться появления ECHILD бесполезно.
>  >
>  > Логика, как мне кажется, ошибочна... ECHILD приходит, когда последний
>  > процесс умирает.
>
>  Почему вы так решили?
>

Потому, что обработчик сигнала так устроен. Когда приходит сигнал
SIGCHILD от последнего процесса, обработчик пытается запустить цикл
для других возможных зомби. И, поскольку это был последний процесс,
сразу же получает ECHILD.

ECHILD (for waitpid() or waitid()) The process specified by pid
(waitpid()) or idtype and id (waitid()) does not exist or is not a
child  of the calling process.  (This can happen for one's own child
if the action for SIGCHLD is set to SIG_IGN.  See also the Linux Notes
section about threads.)

>  "The waitpid() function shall fail if:
>  [ECHILD] The process specified by pid does not exist or is not a child of
>  the calling process, or the process group specified by pid does not exist
>  or does not have any member process that is a child of the calling
>  process."
>
>  Пример:
>
>  $ cat waitpid.c
>  #include <sys/wait.h>
>  int main(void)
>  {
>         int status;
>         waitpid(-1, &status, WNOHANG);
>         waitpid(-1, &status, WNOHANG);
>         return 0;
>  }
>
>  $ strace -qe waitpid ./waitpid
>  waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
>  waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
>

Странный пример, у него же нет потомков, и нет обработчика SIGCHILD.
Но он демонстрирует, что ECHILD приходит.

>  > Приход именно этого сигнала выдавал предупреждение,
>  > когда не до конца ожидался момент умирания всех процессов перед
>  > отмонтированием. По сути получается так, что при умирании последнего
>  > процесса, цикл в обработчике сигнала вынужден получить такую ошибку.
>  > Поэтому отключение обработчика сигнала перед циклом ожидания
>  > неверно...
>
>  Отключение обработчика сигнала?  Мы точно говорим про один и тот же код?
>

Да, я понял, что ошибся... То, что я писал про chld_handler(0)
неверно... Только толку в нём немного, хотя можно и оставить... вдруг
все процессы уже завершились, но каким-то образом последний не прислал
SIGCHILD.

>
>  > Это же подтверждено не практике. В моём случае стоит
>  > ожидание только по этому сигналу, иначе цикл в killall() у меня вообще
>  > не завершится... Но он завершается, а следовательно ECHILD, как и
>  > ожидается, приходит...
>
>  ECHILD у init произойдёт только в случае если в системе не останется
>  процессов, у которых ppid==1; такое может произойти, но может и не
>  произойти.  У нас на стенде init не получал ECHILD ни разу.
>

Такое обязательно произойдёт, если этого дождаться... Иначе нет
никакой гарантии, что процессы, занявшие ресурсы /mnt/destination
завершены. В коде же инсталятора это ожидание раньше полагалось на
секунду после первого общего сигнала. А то, что оно не происходило
означает, что никогда не было момента, чтобы последний сигнал был
получен и успел быть обработан. Хотя конечно это странно...

ECHILD может быть не получен, только, если последний процесс не
пришлёт SIGCHILD... Если такое вдруг произойдёт, то таймаут, конечно,
выход...

Текущий вариант (когда превратиться в alt14) должен быть вполне
работоспособен... Вот только 5 секунд - это маловато... Ведь sleep()
прерывается во время прихода сигнала и, при интенсивном приходе
SIGCHILD на этапе ожидания завершения процессов, может пять раз подряд
прерваться может. И никакой гарантии, что 6 и 7 процессы ещё не
завершились нет. Статистически же поймать это будет теперь ещё
сложнее...

-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

On Wed, Apr 16, 2008 at 04:03:19AM +0400, Evgeny Sinelnikov wrote:
> >  $ strace -qe waitpid ./waitpid
> >  waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
> >  waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
> 
> Странный пример, у него же нет потомков, и нет обработчика SIGCHILD.
> Но он демонстрирует, что ECHILD приходит.

Он демонстрирует, что повторный waitpid снова приводит к ECHILD.

> >  > Это же подтверждено не практике. В моём случае стоит
> >  > ожидание только по этому сигналу, иначе цикл в killall() у меня вообще
> >  > не завершится... Но он завершается, а следовательно ECHILD, как и
> >  > ожидается, приходит...
> >
> >  ECHILD у init произойдёт только в случае если в системе не останется
> >  процессов, у которых ppid==1; такое может произойти, но может и не
> >  произойти.  У нас на стенде init не получал ECHILD ни разу.
> 
> Такое обязательно произойдёт, если этого дождаться... Иначе нет
> никакой гарантии, что процессы, занявшие ресурсы /mnt/destination
> завершены. В коде же инсталятора это ожидание раньше полагалось на
> секунду после первого общего сигнала. А то, что оно не происходило
> означает, что никогда не было момента, чтобы последний сигнал был
> получен и успел быть обработан. Хотя конечно это странно...
> 
> ECHILD может быть не получен, только, если последний процесс не
> пришлёт SIGCHILD... Если такое вдруг произойдёт, то таймаут, конечно,
> выход...

ECHILD может не случиться, если в системе остался хотя бы один процесс
с ppid==1, который не собирается завершаться.  На нашем стенде это
происходит всегда.

> Текущий вариант (когда превратиться в alt14) должен быть вполне
> работоспособен... Вот только 5 секунд - это маловато...

А вот мне кажется, что и 5 секунд многовато.  Не договоримся. :)

> Ведь sleep()
> прерывается во время прихода сигнала и, при интенсивном приходе
> SIGCHILD на этапе ожидания завершения процессов, может пять раз подряд
> прерваться может. И никакой гарантии, что 6 и 7 процессы ещё не
> завершились нет. Статистически же поймать это будет теперь ещё
> сложнее...

Можно использовать альтернативную реализацию sleep(3), например:

static void mysleep(time_t sec)
{
	struct timespec req = { sec, 0 }, rem;

	for (; req.tv_sec || req.tv_nsec; req = rem)
		if (!nanosleep(&req, &rem))
			break;
}


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Evgeny Sinelnikov]

2008/4/16 Dmitry V. Levin <ldv@altlinux.org>:
> On Wed, Apr 16, 2008 at 04:03:19AM +0400, Evgeny Sinelnikov wrote:
>  > >  $ strace -qe waitpid ./waitpid
>  > >  waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
>  > >  waitpid(-1, 0xbf88880c, WNOHANG)        = -1 ECHILD (No child processes)
>  >
>  > Странный пример, у него же нет потомков, и нет обработчика SIGCHILD.
>  > Но он демонстрирует, что ECHILD приходит.
>
>  Он демонстрирует, что повторный waitpid снова приводит к ECHILD.
>
>
>  > >  > Это же подтверждено не практике. В моём случае стоит
>  > >  > ожидание только по этому сигналу, иначе цикл в killall() у меня вообще
>  > >  > не завершится... Но он завершается, а следовательно ECHILD, как и
>  > >  > ожидается, приходит...
>  > >
>  > >  ECHILD у init произойдёт только в случае если в системе не останется
>  > >  процессов, у которых ppid==1; такое может произойти, но может и не
>  > >  произойти.  У нас на стенде init не получал ECHILD ни разу.
>  >
>  > Такое обязательно произойдёт, если этого дождаться... Иначе нет
>  > никакой гарантии, что процессы, занявшие ресурсы /mnt/destination
>  > завершены. В коде же инсталятора это ожидание раньше полагалось на
>  > секунду после первого общего сигнала. А то, что оно не происходило
>  > означает, что никогда не было момента, чтобы последний сигнал был
>  > получен и успел быть обработан. Хотя конечно это странно...
>  >
>  > ECHILD может быть не получен, только, если последний процесс не
>  > пришлёт SIGCHILD... Если такое вдруг произойдёт, то таймаут, конечно,
>  > выход...
>
>  ECHILD может не случиться, если в системе остался хотя бы один процесс
>  с ppid==1, который не собирается завершаться.  На нашем стенде это
>  происходит всегда.
>

Даже когда ему SIGKILL отправили не отрывается... ? Хм... Ну, всякое
бывает, но это какие-то проблемы ядра. Сизифный вариант на 2.6.24
такого не давал ни разу.... Теперь понятно почему ранее не выявлялся
баг с killall()...

>
>  > Текущий вариант (когда превратиться в alt14) должен быть вполне
>  > работоспособен... Вот только 5 секунд - это маловато...
>
>  А вот мне кажется, что и 5 секунд многовато.  Не договоримся. :)
>

Ну, скажем так, пока это вероятно приемлимо...

>
>  > Ведь sleep()
>  > прерывается во время прихода сигнала и, при интенсивном приходе
>  > SIGCHILD на этапе ожидания завершения процессов, может пять раз подряд
>  > прерваться может. И никакой гарантии, что 6 и 7 процессы ещё не
>  > завершились нет. Статистически же поймать это будет теперь ещё
>  > сложнее...
>
>  Можно использовать альтернативную реализацию sleep(3), например:
>
>  static void mysleep(time_t sec)
>  {
>         struct timespec req = { sec, 0 }, rem;
>
>         for (; req.tv_sec || req.tv_nsec; req = rem)
>                 if (!nanosleep(&req, &rem))
>                         break;
>  }
>

Как-то оно не очень... Вся прелесть была как раз в том, что sleep()
отрывался после очередной обработки сигнала и, если это был последний
процесс, то переменная got_ECHILD была уже установлена... Холостое
ожидание было сведено к минимуму... Если конечно таких багов не было
бы, когда процессы зависают... А для того, чтобы этот процесс был
виден точки рисуютс как раз... У меня ни разу не было видно как они
рисуются... Моментально пробегают и тут же ECHILD ловится....


-- 
Sin (Sinelnikov Evgeny)

[devel] насчёт SIGKILL

[Michael Shigorin]

On Wed, Apr 16, 2008 at 06:01:27AM +0400, Evgeny Sinelnikov wrote:
> Даже когда ему SIGKILL отправили не отрывается... ? Хм... Ну,
> всякое бывает, но это какие-то проблемы ядра.

Процесс, залипший на i/o, не отреагирует на SIGKILL.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] насчёт SIGKILL

[Serge Ryabchun]

21.04.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
> On Wed, Apr 16, 2008 at 06:01:27AM +0400, Evgeny Sinelnikov wrote:
>  > Даже когда ему SIGKILL отправили не отрывается... ? Хм... Ну,
>  > всякое бывает, но это какие-то проблемы ядра.
>
>  Процесс, залипший на i/o, не отреагирует на SIGKILL.

В 2.6.25 у процесса теперь статус может быть KILLABLE, уже можно убивать

Re: [devel] насчёт SIGKILL

[Andrew Avramenko]

Простите, я немного выпадаю из контекста вопроса:

Это относится ко всем процессам или только к повисшим из-за
недоступности NFS-шары. На сколько мне известно - второе. Если не так,
поправьте меня пожалуйста.



21 апреля 2008 г. 19:16 пользователь Serge Ryabchun
<serge.ryabchun@gmail.com> написал:
> 21.04.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
>
> > On Wed, Apr 16, 2008 at 06:01:27AM +0400, Evgeny Sinelnikov wrote:
>  >  > Даже когда ему SIGKILL отправили не отрывается... ? Хм... Ну,
>  >  > всякое бывает, но это какие-то проблемы ядра.
>  >
>  >  Процесс, залипший на i/o, не отреагирует на SIGKILL.
>
>  В 2.6.25 у процесса теперь статус может быть KILLABLE, уже можно убивать
>
>
> _______________________________________________
>  Devel mailing list
>  Devel@lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/devel



-- 
With best regards,
Andrew