[devel] hasher vs SysV IPC

[devel] hasher vs SysV IPC

[Alexey Tourbin]

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

Господа,

когда появится ядро 2.4.x, на котором можно будет пользоваться hasher'ом
больше трёх раз?  Думаю, что появление такого ядра будет соответствовать
стратегической линиии развития ALT Linux Team. :)

$ hsh ~/build /home/at/RPM/SRPMS/tklua-4.0-alt1a.src.rpm
Components: hasher
Processing pkglists... hasher done
Processing srclists...  hasher done
Creating component releases... done
Updating global release file... done
Appending MD5Sum... hasher done
All your base are belong to us!!!
depmod: Can't open /lib/modules/2.4.21rel-std-up-alt9/modules.dep for writing
fakeroot, while creating message channels: No space left on device
This may be due to a lack of SYSV IPC support.
fakeroot: error while starting the `faked' daemon.
install: packages installation failed.
$

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

Re: [devel] hasher vs SysV IPC

[Dmitry Lebkov]

On Sun, 24 Aug 2003 21:43:56 +0400
Alexey Tourbin <at@altlinux.ru> wrote:

> Господа,
> 
> когда появится ядро 2.4.x, на котором можно будет пользоваться
> hasher'ом больше трёх раз?  Думаю, что появление такого ядра будет
> соответствовать стратегической линиии развития ALT Linux Team. :)

Вот вроде рабочая связка:

2.4.21rel-std-smp-alt8 + hasher-0.5-alt1 + последний Сизиф

Нормально живет на Asus P2B-DS (2xPIII-500) и Asus P4B533 (P4-2.6).
Раньше, по каким-то неизвестным причинам, hasher нормально жил на
P2B-DS и не закрывал ipc-очереди и семафоры на 	P4B533. Набор софта
на этих двух машинах полностью одинаков.

--
WBR, Dmitry Lebkov

[devel] Re: hasher vs SysV IPC

[Alexey Tourbin]

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

On Mon, Aug 25, 2003 at 09:14:00AM +1100, Dmitry Lebkov wrote:
> Вот вроде рабочая связка:
> 
> 2.4.21rel-std-smp-alt8 + hasher-0.5-alt1 + последний Сизиф
> 
> Нормально живет на Asus P2B-DS (2xPIII-500) и Asus P4B533 (P4-2.6).
> Раньше, по каким-то неизвестным причинам, hasher нормально жил на

Нормально живет -- очереди закрывает?

$ time sh -c 'while :; do hsh ~/build favorite.src.rpm; done'

Сколько будет работать?

> P2B-DS и не закрывал ipc-очереди и семафоры на 	P4B533. Набор софта
> на этих двух машинах полностью одинаков.

Вы хотите сказать, что это от матери зависит, закрываются ipc очереди
или нет?  М-м...

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

Re: [devel] Re: hasher vs SysV IPC

[Dmitry Lebkov]

On Mon, 25 Aug 2003 12:49:57 +0400
Alexey Tourbin <at@altlinux.ru> wrote:

> On Mon, Aug 25, 2003 at 09:14:00AM +1100, Dmitry Lebkov wrote:
> > Вот вроде рабочая связка:
> > 
> > 2.4.21rel-std-smp-alt8 + hasher-0.5-alt1 + последний Сизиф
> > 
> > Нормально живет на Asus P2B-DS (2xPIII-500) и Asus P4B533 (P4-2.6).
> > Раньше, по каким-то неизвестным причинам, hasher нормально жил на
> 
> Нормально живет -- очереди закрывает?
> 
> $ time sh -c 'while :; do hsh ~/build favorite.src.rpm; done'
> 
> Сколько будет работать?

:))) Живет до упора. Хотя по граблям с leak'аньем очередей сообщений
и семафоров я уже ходил %). Работа заканчивалась после того, как
заканчивались свободные очереди. См. sysctl-параметр kernel.msgmni и
посты в devel@ от "5 Jul 2003 03:02:26 +1100" с темой "[devel] hasher
testing ...".

> > P2B-DS и не закрывал ipc-очереди и семафоры на P4B533. Набор
> > софта на этих двух машинах полностью одинаков.
> 
> Вы хотите сказать, что это от матери зависит, закрываются ipc очереди
> или нет?  М-м...

Врядли от матери. Скорее от наличия второго процессора. Хотя, на
каком-то этапе проверялось на трех (два вышеописанных ASUS'а и
Chaintech на 440BX - Celeron-600) машинах с одним и тем же набором
софта и (вроде) -llc-(up|smp) ядром -- очереди не освобождались на
всех, кроме P2B-DS.

Честно говоря, я уже и не знал на что грешить и просто ждал очередного
smp-ядра и пробовал ...


--
WBR, Dmitry Lebkov

[devel] Re: hasher vs SysV IPC

[Grigory Batalov]

On Sun, 24 Aug 2003 21:58:33 +1100
Dmitry Lebkov <dima@sakhalin.ru> wrote:

> > > Вот вроде рабочая связка:
> > > 
> > > 2.4.21rel-std-smp-alt8 + hasher-0.5-alt1 + последний Сизиф
> > > 
> > > Нормально живет на Asus P2B-DS (2xPIII-500) и Asus P4B533 (P4-2.6).
> > > Раньше, по каким-то неизвестным причинам, hasher нормально жил на
> > 
> > Нормально живет -- очереди закрывает?
> > 
> > $ time sh -c 'while :; do hsh ~/build favorite.src.rpm; done'
> > 
> > Сколько будет работать?
> 
> :))) Живет до упора. Хотя по граблям с leak'аньем очередей сообщений
> и семафоров я уже ходил %). Работа заканчивалась после того, как
> заканчивались свободные очереди. См. sysctl-параметр kernel.msgmni и
> посты в devel@ от "5 Jul 2003 03:02:26 +1100" с темой "[devel] hasher
> testing ...".

  Значение msgmni также оказывает влияние на скорость создания
  базы в Oracle 8.1.7.4. При 512 возникают 3-секундные простои
  после 1-2 секунд работы (это видно при запуске catalog.sql и
  catproc.sql). С увеличением до 65535 простои исчезли.

$ uname -r
2.4.20-alt9-smp

-- 
Григорий Баталов,
группа техподдержки
ОАО "Ковдорский ГОК"

[devel] Re: hasher vs SysV IPC

[Alexey Tourbin]

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

On Mon, Aug 25, 2003 at 12:49:57PM +0400, Alexey Tourbin wrote:
> $ time sh -c 'while :; do hsh ~/build favorite.src.rpm; done'

Вернее, так:

$ time sh -c 'while :; do hsh ~/build favorite.src.rpm || exit $?; done'

ну или ещё как...

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

[devel] Re: hasher vs SysV IPC

[Michael Shigorin]

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

On Mon, Aug 25, 2003 at 12:49:57PM +0400, Alexey Tourbin wrote:
> > P2B-DS и не закрывал ipc-очереди и семафоры на 	P4B533.
> > Набор софта на этих двух машинах полностью одинаков.
> Вы хотите сказать, что это от матери зависит, закрываются ipc
> очереди или нет?  М-м...

Вроде бы именно так.

В качестве bloody hackaround кто-то советовал нечто вроде 

trickster:~> sudo tail -2 /etc/sysctl.conf
# workaround flakey IPC-wise hasher
kernel.msgmni = 512

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

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

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Wed, Aug 27, 2003 at 03:42:04PM +0300, Michael Shigorin wrote:
> On Mon, Aug 25, 2003 at 12:49:57PM +0400, Alexey Tourbin wrote:
> > > P2B-DS и не закрывал ipc-очереди и семафоры на 	P4B533.
> > > Набор софта на этих двух машинах полностью одинаков.
> > Вы хотите сказать, что это от матери зависит, закрываются ipc
> > очереди или нет?  М-м...
> 
> Вроде бы именно так.
> 
> В качестве bloody hackaround кто-то советовал нечто вроде 
> 
> trickster:~> sudo tail -2 /etc/sysctl.conf
> # workaround flakey IPC-wise hasher
> kernel.msgmni = 512

Тогда понятно, почему на ядрах от ALM2.2 работает - там это значение 512
по умолчанию.


-- 
ldv

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

[devel] Re: hasher vs SysV IPC

[Alexey Tourbin]

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

On Wed, Aug 27, 2003 at 03:42:04PM +0300, Michael Shigorin wrote:
> trickster:~> sudo tail -2 /etc/sysctl.conf
> # workaround flakey IPC-wise hasher
> kernel.msgmni = 512

Непамагает.

$ sysctl kernel.msgmni
kernel.msgmni = 2048
$

fakeroot, while creating message channels: Invalid argument
This may be due to a lack of SYSV IPC support.
fakeroot: error while starting the `faked' daemon.
initroot: failed to install initial package list.

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

[devel] Re: hasher vs SysV IPC

[Michael Shigorin]

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

On Wed, Sep 03, 2003 at 06:19:42PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 27, 2003 at 03:42:04PM +0300, Michael Shigorin wrote:
> > trickster:~> sudo tail -2 /etc/sysctl.conf
> > # workaround flakey IPC-wise hasher
> > kernel.msgmni = 512
> Непамагает.

Мне помогает на достаточно долгий срок.  Материнка, видимо,
другая...

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

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

[devel] Re: hasher vs SysV IPC

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 447 bytes --]

On Wed, Sep 03, 2003 at 05:29:23PM +0300, Michael Shigorin wrote:
> On Wed, Sep 03, 2003 at 06:19:42PM +0400, Alexey Tourbin wrote:
> > On Wed, Aug 27, 2003 at 03:42:04PM +0300, Michael Shigorin wrote:
> > > trickster:~> sudo tail -2 /etc/sysctl.conf
> > > # workaround flakey IPC-wise hasher
> > > kernel.msgmni = 512
> > Непамагает.
> 
> Мне помогает на достаточно долгий срок.  Материнка, видимо,
> другая...

Кувалда от перезагрузки памагает.

[-- Attachment #1.2: clear_ipc --]
[-- Type: text/plain, Size: 191 bytes --]

#!/bin/sh

[ $EUID -gt 0 ] && exec sudo $0
ipcs | awk '/semid/,/^$/ {print $2}' | grep '[0-9]' | xargs -rn1 ipcrm -s
ipcs | awk '/msqid/,/^$/ {print $2}' | grep '[0-9]' | xargs -rn1 ipcrm -q

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

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Wed, Sep 03, 2003 at 06:19:42PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 27, 2003 at 03:42:04PM +0300, Michael Shigorin wrote:
> > trickster:~> sudo tail -2 /etc/sysctl.conf
> > # workaround flakey IPC-wise hasher
> > kernel.msgmni = 512
> 
> Непамагает.
> 
> $ sysctl kernel.msgmni
> kernel.msgmni = 2048
> $
> 
> fakeroot, while creating message channels: Invalid argument
> This may be due to a lack of SYSV IPC support.
> fakeroot: error while starting the `faked' daemon.
> initroot: failed to install initial package list.

Если ядро не очищает SYSV IPC за процессами (как в -ow), то и ограничение
в 2048 может быть достигнуто.

Выходов два:
1. Использовать ядра с включённой очисткой SYSV IPC.
2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
  hasher-priv killuid{1,2}).

Какие будут предложения?


-- 
ldv

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

Re: [devel] Re: hasher vs SysV IPC

[Dmitry Lebkov]

On Sat, 6 Sep 2003 00:18:23 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

[skip]

> Выходов два:
> 1. Использовать ядра с включённой очисткой SYSV IPC.
> 2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
>   hasher-priv killuid{1,2}).
> 
> Какие будут предложения?

Я думаю, второй вариант предпочтительней.

--
WBR, Dmitry Lebkov

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Sat, Sep 06, 2003 at 04:50:09PM +1100, Dmitry Lebkov wrote:
[...]
> > Выходов два:
> > 1. Использовать ядра с включённой очисткой SYSV IPC.
> > 2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
> >   hasher-priv killuid{1,2}).
> > 
> > Какие будут предложения?
> 
> Я думаю, второй вариант предпочтительней.

Implemented in hasher-priv-0.4-alt1.


-- 
ldv

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

[devel] Re: hasher vs SysV IPC

[Sergey Vlasov]

On Sun, 7 Sep 2003 13:00:22 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> On Sat, Sep 06, 2003 at 04:50:09PM +1100, Dmitry Lebkov wrote:
> [...]
> > > Выходов два:
> > > 1. Использовать ядра с включённой очисткой SYSV IPC.
> > > 2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
> > >   hasher-priv killuid{1,2}).
> > > 
> > > Какие будут предложения?
> > 
> > Я думаю, второй вариант предпочтительней.
> 
> Implemented in hasher-priv-0.4-alt1.

Вообще-то настоящая проблема в том, что в fakeroot присутствует race:
faked там убивается через trap "kill -s TERM $PID" EXIT INT, но скрипт
fakeroot не дожидается завершения его работы. Видимо, killuid1
успевает грохнуть faked раньше, чем он подчистит за собой.

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Fri, Sep 12, 2003 at 12:05:02PM +0400, Sergey Vlasov wrote:
> > [...]
> > > > Выходов два:
> > > > 1. Использовать ядра с включённой очисткой SYSV IPC.
> > > > 2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
> > > >   hasher-priv killuid{1,2}).
> > > > 
> > > > Какие будут предложения?
> > > 
> > > Я думаю, второй вариант предпочтительней.
> > 
> > Implemented in hasher-priv-0.4-alt1.
> 
> Вообще-то настоящая проблема в том, что в fakeroot присутствует race:
> faked там убивается через trap "kill -s TERM $PID" EXIT INT, но скрипт
> fakeroot не дожидается завершения его работы. Видимо, killuid1
> успевает грохнуть faked раньше, чем он подчистит за собой.

Да, я знаю.
Но проблема, как уже говорилось, несколько шире:
hasher, согласно архитектуре, должен обеспечивать возврат всех возможных
ресурсов системе.  Поскольку SysV IPC могут остаться после завершения
процессов, их надо освобождать специально.


-- 
ldv

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

Re: [devel] Re: hasher vs SysV IPC

[Denis Ovsienko]

> Если ядро не очищает SYSV IPC за процессами (как в -ow), то и ограничение
> в 2048 может быть достигнуто.
>
> Выходов два:
> 1. Использовать ядра с включённой очисткой SYSV IPC.
> 2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
>   hasher-priv killuid{1,2}).
>
> Какие будут предложения?
Господа, я читаю вашу газету и худею. Если бы вы программировали под IPC
хотя бы некоторое время, то знали бы, что ресурсы по умолчанию не
удаляются, когда счётчик процессов, их использующих, достигает нуля (то
есть количество вызовов shmdt равняется количеству вызовов shmat). Чтобы
удалялись, выставляется флаг с помощью shmctl (shmid, IPC_RMID, buf). Для
семафоров аналогично.

--
    DO4-UANIC

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Sat, Sep 06, 2003 at 09:49:36AM +0300, Denis Ovsienko wrote:
> > Если ядро не очищает SYSV IPC за процессами (как в -ow), то и ограничение
> > в 2048 может быть достигнуто.
> >
> > Выходов два:
> > 1. Использовать ядра с включённой очисткой SYSV IPC.
> > 2. Продублировать код из ipcs/ipcrm в hasher'е (точнее говоря, в
> >   hasher-priv killuid{1,2}).
> >
> > Какие будут предложения?
> Господа, я читаю вашу газету и худею. Если бы вы программировали под IPC
> хотя бы некоторое время, то знали бы, что ресурсы по умолчанию не
> удаляются, когда счётчик процессов, их использующих, достигает нуля (то
> есть количество вызовов shmdt равняется количеству вызовов shmat). Чтобы
> удалялись, выставляется флаг с помощью shmctl (shmid, IPC_RMID, buf). Для
> семафоров аналогично.

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

Например, в ow-ядрах есть параметр:

Destroy shared memory segments not in use
CONFIG_HARDEN_SHM
  Linux lets you set resource limits, including on how much memory one
  process can consume, via setrlimit(2). Unfortunately, shared memory
  segments are allowed to exist without association with any process,
  and thus might not be counted against any resource limits. This option
  automatically destroys shared memory segments when their attach count
  becomes zero after a detach or a process termination. It will also
  destroy segments that were created, but never attached to, on exit from
  the process. (In case you're curious, the only use left for IPC_RMID is
  to immediately destroy an unattached segment.) Of course, this breaks
  the way things are defined, so some applications might stop working.
  Note that this feature will do you no good unless you also configure
  your resource limits (in particular, RLIMIT_AS and RLIMIT_NPROC).

Вообще говоря, portable software не должно полагаться на то или иное
поведение ядра в этой ситуации.


-- 
ldv

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

[devel] Re: hasher vs SysV IPC

[Mikhail Zabaluev]

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

Hello Dmitry,

On Sat, Sep 06, 2003 at 11:21:34AM +0400, Dmitry V. Levin wrote:
>
> Вообще говоря, portable software не должно полагаться на то или иное
> поведение ядра в этой ситуации.

А нельзя как-либо обойтись без столь проблематичного средства,
как сегменты разделяемой памяти? Например, mmap-ировать общий файл,
или вообще обойтись без механизма совместно используемой памяти.

Кстати, если нужна _переносимая_ реализация разделяемой памяти,
рекомендую взглянуть на libmm. Там большинство грабель уже
наступлены на.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
They also serve who only stand and wait.
		-- John Milton

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

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Sat, Sep 06, 2003 at 11:36:18AM +0400, Mikhail Zabaluev wrote:
> On Sat, Sep 06, 2003 at 11:21:34AM +0400, Dmitry V. Levin wrote:
> >
> > Вообще говоря, portable software не должно полагаться на то или иное
> > поведение ядра в этой ситуации.
> 
> А нельзя как-либо обойтись без столь проблематичного средства,
> как сегменты разделяемой памяти? Например, mmap-ировать общий файл,
> или вообще обойтись без механизма совместно используемой памяти.
> 
> Кстати, если нужна _переносимая_ реализация разделяемой памяти,
> рекомендую взглянуть на libmm. Там большинство грабель уже
> наступлены на.

1. Потребность в SysV IPC вызвана тем, что нельзя использовать файловые
дескрипторы.

2. Что касается libmm, то я не имею ни малейшего желания переписывать
fakeroot на libmm.

3. libmm не решит проблем, поскольку ресурс все равно может и будет
утекать.  Так что придётся подчищать за fakeroot'ом в любом случае.


-- 
ldv

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

Re: [devel] Re: hasher vs SysV IPC

[Denis Ovsienko]

> То, о чём вы говорите, порой не соответствует действительности, хотя об
> этом и написано в старых книжках.
Я этим пользовался и у меня работало именно так на ядрах 2.2

>   destroy segments that were created, but never attached to, on exit from
>   the process. (In case you're curious, the only use left for IPC_RMID is
>   to immediately destroy an unattached segment.) Of course, this breaks
unattached!
При подсоединении ресурса можно установить IPC_RMID и получить
автоматическую сборку IPC-мусора.

> Вообще говоря, portable software не должно полагаться на то или иное
> поведение ядра в этой ситуации.
Это поведение определено для POSIX, насколько я понимаю.
Давайте для однозначности проверим на тестовой программе, хотя очень
сомневаюсь, что 2.4 ядра взяли и вдруг побили IPC, которое уже было
реализовано по POSIX в 2.2.

--
    DO4-UANIC

Re: [devel] Re: hasher vs SysV IPC

[Dmitry V. Levin]

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

On Sat, Sep 06, 2003 at 01:50:49PM +0300, Denis Ovsienko wrote:
> >   destroy segments that were created, but never attached to, on exit from
> >   the process. (In case you're curious, the only use left for IPC_RMID is
> >   to immediately destroy an unattached segment.) Of course, this breaks
> unattached!
> При подсоединении ресурса можно установить IPC_RMID и получить
> автоматическую сборку IPC-мусора.

???


-- 
ldv

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