Я неопределенно помню от своего UNIX (AIX и HPUX, я признаю, что никогда не использовал общую память в Linux), дни, что удаление просто отмечает блок как больше не присоединяемый новыми клиентами.
Это будет только физически удалено в какой-то момент после того, как больше не будет процессов, присоединенных к нему.
Это совпадает с с регулярными файлами, которые удалены, их информация о каталоге удалена, но содержание файла только исчезает после того, как последний процесс закрывает его. Это иногда приводит к файлам журнала, которые занимают все больше места в файловой системе даже после того, как они удалены, как процессы все еще пишут в них, последствие "отсоединения" между указателем файла (нуль или больше записей каталога, указывающих на inode) и содержанием файла (сам inode).
Вы видите от Вашего ipcs
вывод, что 3 из 4 все еще присоединили процессы, таким образом, они не будут идти никуда до тех процессов отсоединение от блоков общей памяти. Других, вероятно, ожидание некоторой функции 'развертки' для чистки его, но это, конечно, зависело бы от реализации общей памяти.
А правильно написанный клиент общей памяти (или файлы журнала в этом отношении) должен периодически повторно прикреплять (или переворачиваться) гарантировать, что эта ситуация является переходной и не влияет на операцию программного обеспечения.
Вы сказали использование следующей команды
ipcrm -M 0x0000162e (this is the key)
Из страницы справочника для ipcrm
-M shmkey Mark the shared memory segment associated with key shmkey for removal. This marked segment will be destroyed after the last detach.
, Таким образом, поведение-M опций делает точно, что Вы наблюдали, т.е. установили сегмент, который будет уничтожен только после последнего отсоединения.