如何停止sem_open()与ENOSYS一起失败? [英] How do I stop sem_open() failing with ENOSYS?
问题描述
我有两个Slackware Linux系统，其POSIX信号量sem_open()调用在errno设置为38时失败.示例代码在下面再现(该代码在CentOS/RedHat上运行良好).
I have two Slackware Linux systems on which the POSIX semaphore sem_open() call fails with errno set to 38. Sample code to reproduce below (the code works fine on CentOS / RedHat).
是否存在任何可能导致此问题的内核或系统配置选项?还有其他建议吗?
Are there any kernel or system configuration options that could cause this? Other suggestions?
有问题的系统是Slackware 10.1.0内核2.6.11/lib/librt-2.3.4.so/lib/libpthread-0.10.so，但是相同的代码可在更老的RedHat 9内核2.4.20上运行/lib/librt-2.3.2.so/lib/tls/libpthread-0.29.so. (并且还可以在CentOS 5内核2.6.18/lib/librt-2.5.so/lib/i686/nosegneg/libpthread-2.5.so上使用.)
Systems with issue are Slackware 10.1.0 kernel 2.6.11 /lib/librt-2.3.4.so /lib/libpthread-0.10.so, but the same code works on the much older RedHat 9 kernel 2.4.20 /lib/librt-2.3.2.so /lib/tls/libpthread-0.29.so. (and also works on CentOS 5 kernel 2.6.18 /lib/librt-2.5.so /lib/i686/nosegneg/libpthread-2.5.so).
man sem_open表示此错误号表示系统不支持sem_open().
man sem_open suggests this errno means sem_open() is not supported by system.
#define ENOSYS 38 /* Function not implemented */
sem_open()用户空间位于我们动态链接的librt中，并且librt存在于受影响的系统中.
The sem_open() userspace is in librt which we link against dynamically and librt is present on the affected systems.
受影响的系统声称支持POSIX信号量:_POSIX_SEMAPHORES是真实的，而sysconf(_SC_SEMAPHORES)证实了这一点.
The affected system claims to support POSIX semaphores: _POSIX_SEMAPHORES is true and sysconf(_SC_SEMAPHORES) confirms this.
谢谢， 基兰(Kieran)
Thanks, Kieran
我添加了有关所使用软件版本的更多详细信息，并删除了一些不相关的注释.
Edit 1: I've added more detail on the software versions in use and removed some irrelevant comments.
/dev/shm安装在正常系统上，而不安装在不良系统上.挂载它不会改变受影响系统上的行为.我认为/dev/shm也是必要的，但是sem_open()在此之前失败了，而strace支持这一点.
Edit 2: /dev/shm is mounted on the good systems and not mounted on the bad systems. Mounting it did not change the behaviour on the affected systems. I think /dev/shm is necessary too but sem_open() is failing before that, and strace supports this.
# /* Quick'n'dirty test program to illustrate sem_open failure
#Run this file to auto-build test and run as a.out
# Build
gcc $0 -lrt
if [ $? -ne 0 ] ; then exit ; fi
# Run
$( dirname $0)/a.out
exit
*/
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <semaphore.h>
int main(int argc, char *argv[]) {
const char *SEM_NAME = "SHRMEM_SCXL"; /* name of mutex */
sem_t *mutex = SEM_FAILED; /* ptr to mutex */
#ifdef _POSIX_SEMAPHORES
printf("_POSIX_SEMAPHORES %ld\n", _POSIX_SEMAPHORES);
#else
puts("Undefined");
#endif
printf("sysconf %s\n", sysconf(_SC_SEMAPHORES) ? "Yes" : "No" );
mutex = sem_open(SEM_NAME, O_CREAT, 0666, 1);
if (mutex == SEM_FAILED) printf("Failed %d\n", errno);
else {
puts("Success - pause while you check /dev/shm ");
sleep(5);
sem_close(mutex);
sem_unlink(SEM_NAME);
}
}
推荐答案
/dev/shm是否已安装?较早版本的slackware可能在引导时尚未挂载此文件系统.在/etc/fstab中:
Is /dev/shm mounted? Older versions of slackware may not have mounted this filesystem at boot. From /etc/fstab:
tmpfs /dev/shm tmpfs defaults 0 0
毕竟那可能不是问题.我认为您可能只需要升级内核甚至是librt.
That is probably not the problem after all. I think you may just need to upgrade your kernel or maybe even librt.
Edit2:我认为对于您正在使用的slackware 11，您需要一个高于2.6.13的内核才能使用NPTL线程库(/lib/tls中的库)，而这似乎是必需的. sem_open开始工作.
I think that for slackware 11, which I think you are using, you'll need a kernel newer than 2.6.13 to use the NPTL threading libraries (libs in /lib/tls) which appear to be required for the sem_open to work.
Edit3:我设法通过a)挂载/dev/shm和b)将环境变量LD_ASSUME_KERNEL设置为2.6.13(任何内核版本> 2.6.12可以)来使它与我拥有的slackware 11盒一起使用.工作).即使内核是2.6.11.11，这似乎仍然有效，但是诸如线程之类的其他东西可能就不行了.
I managed to get it to work with a slackware 11 box I have by a) mounting /dev/shm and b) setting the environment variable LD_ASSUME_KERNEL to 2.6.13 (any kernel version > 2.6.12 will work). That seems to work even though the kernel is 2.6.11.11, but other things like threads might not.
这篇关于如何停止sem_open()与ENOSYS一起失败?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
