我在使用我支持的应用程序时遇到一些问题，出于各种烦人的原因， fork 工作进程来处理某些任务。这些进程使用共享内存空间来传达状态，有时还会传达结果。我正在使用 boost 进程间库来完成此任务(使用 shared_memory_object 和 mapped_region 类型)。
在部署到的系统之一上，我们的访问权限极其有限，因此很难在该系统上进行调试。有一个完整的过程只是为了安装新版本的软件。但是在这个目标上，我们遇到了一个问题，一个用户试图启动应用程序，能够很好地启动应用程序，而另一个用户，具有看似相同的凭据、组从属关系等，无法创建共享内存对象。 boost 错误是“权限被拒绝”。对于任何创建共享内存对象的尝试都会返回此值，即使该名称尚不存在。
我只能通过以 root 身份启动应用程序来重现此问题，这样内存空间就以受限权限创建，然后以非 root 用户身份重新运行，这会产生相同的权限问题。我可以通过调用权限对象上的 set_unrestricted 例程来解决这个问题，如前所述 here .但是，这不是此远程系统上发生的情况，因为两个用户都不是 root，并且一个用户不能创建任何命名的内存对象，即使是新的。
那么我的问题是还有哪些其他原因可能会阻止一个用户打开共享内存对象？我只发现提到了根/非根限制，但我找不到任何其他可能的解释。
这是使用 boost 1.55 进程间库在 Linux 系统上创建共享内存对象。
最佳答案
检查
- /dev/shm 权限(也在/dev/目录上 +x)
librt.so的可用性/可访问性>- ulimit 生效
- 主要和次要组的
id输出 - SELinux 配置(getenforce、setenforce 0)
- AppArmor(不太可能是此类系统的罪魁祸首，但仍然如此)
此外，并非所有内核都编译了 SHM 支持，但这似乎并不是这里的问题。
关于c++ - 用户可能无法在 Linux 系统上打开共享内存对象的原因，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30850686/