Проблема с общей памятью и контейнером Cloudfoundry с php exec с использованием библиотеки interprocess boost - PullRequest
Новая
       28

Проблема с общей памятью и контейнером Cloudfoundry с php exec с использованием библиотеки interprocess boost

0 голосов
/ 29 января 2019

У нас есть собственный php-buildpack, работающий в облачном контейнере.Проблема в том, что запуск apache -> php-fpm (здесь код общей памяти работает нормально).php-fpm exec () php-скрипты, которые запускаются -> php-cli (это дамп ядра для кода общей памяти).

Для разделяемой памяти мы используем boost-1.56.0 Пример: - 

<?php
 exec("php  anotherscript.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)?

1 Ответ

0 голосов
/ 30 января 2019

Администратору 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, которому может потребоваться специальный параметр для размера общей памяти.

...