How do I stop sem_open() failing with ENOSYS?

Question

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?

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 suggests this errno means sem_open() is not supported by system.

#define ENOSYS          38      /* Function not implemented */

The sem_open() userspace is in librt which we link against dynamically and librt is present on the affected systems.

The affected system claims to support POSIX semaphores: _POSIX_SEMAPHORES is true and sysconf(_SC_SEMAPHORES) confirms this.

Thanks, Kieran

Edit 1: I've added more detail on the software versions in use and removed some irrelevant comments.

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);
 }
}

Answer 1

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

Edit: That is probably not the problem after all. I think you may just need to upgrade your kernel or maybe even librt.

Edit2: 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: 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.

Answer 2

I was working with posix message queues i have got the same error mq_open was failed with errono 38 (ENOSYS).

The work arround is to rebuild the kenel with POSIX MESSGE QUEUE enabled in the kernel configuration.

This will build the kernel with POSIX message queue support and it worked for me.

Thanks

Answer 3

Older versions of the threading libraries don't support sharing POSIX semaphores between processes. From man sem_init

The pshared argument indicates whether the semaphore is local to the current process ( pshared is zero) or is to be shared between several processes ( pshared is not zero). LinuxThreads currently does not support process-shared semaphores, thus sem_init always returns with error ENOSYS if pshared is not zero.

As sem_open() creates named semaphores, it always tries to share them between processes.

To support sharing anonymous semaphores between processes with sem_init() on Slackware 10

• upgrade libpthread and (possibly) librt
• upgrade the kernel

Additionally, to support sharing named semaphores with sem_open()

• add a line to /etc/fstab to mount /dev/shm as a tmpfs

  tmpfs /dev/shm tmpfs defaults 0 0

• run mount /dev/shm or reboot

Answer 4

The "process shared sema4s don't work" hypothesis makes some sense to me. Not that it helps you, but if you have time and inclination you might want to try the following, to see whether the "process-shared" aspect is what is failing:

1. create a semaphore using sem_init in unshared memory (for threads). If it works then sema4s work within the process.

2. repeat experiment in shared memory. This should tell you if they work between processes. Note that you may need to actually try to USE the sema4 to see whether it works between processes.

Answer 5

Another way to share a semaphore across processes is to use SystemV semaphores.

These do work even where shared POSIX semaphores don't (at least on the systems described above.).

See http://www.linuxdevcenter.com/pub/a/linux/2007/05/24/semaphores-in-linux.html for examples of the two types of semaphore use.