У нас есть собственный php-buildpack, работающий в облачном контейнере.
Проблема в том, что запуск apache -> php-fpm (здесь код общей памяти работает нормально). php-fpm exec () php-скрипты, которые запускаются -> php-cli (это дамп ядра на код разделяемой памяти).
Для разделяемой памяти мы используем boost-1.56.0
Пример :-
<?php
exec("php anotherscript.php");
?>
<?php
custom extention call i.e c/c++ code
?>
==========
sample.cpp (создать общую память, используя boost)
permissions perms;
perms.set_unrestricted();
managed_shared_memory segment(create_only, SharedDataShmSegmentName, segmentSize, 0, perms);
interprocess_sharable_mutex *mutex= segment.construct<interprocess_sharable_mutex>(SharedDataShmMutexName)();
Это дает дамп ядра как —
Signal 11 (segmentation fault)(core dumped)
Мы подозреваем, что дочерний exec () будет иметь меньше привилегий, чем главный процесс, или дочерний exec () не будет иметь разрешения на использование совместно используемой памяти, например, возможности CAP_IPC_LOCK.
Существует ли проблема с дочерним процессом контейнера Cloudfoundry, созданным exec () с общей памятью (boost — 1.56.0)?
Ваш администратор Cloud Foundry должен включить привилегированные контейнеры, в противном случае CF сбрасывается CAP_IPC_LOCK
возможность. Увидеть https://docs.cloudfoundry.org/concepts/container-security.html
Также разделяемая память — это «особая» память. Например, Docker по умолчанию позволяет использовать только 64 МБ общей памяти. Конечно, его можно увеличить по специальному параметру --shm-size=""
— увидеть https://docs.docker.com/engine/reference/run/
Но CF не использует Docker, а Garden-runC, которому может потребоваться специальный параметр для размера разделяемой памяти.
Других решений пока нет …