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