Programs on our web server machine recently started complaining about being unable to set up semaphores (well, once we figured out what the error message meant). This rapidly sent us on an expedition into the underdocumented mists of the kernel.sem sysctl, and so I'll write down what I've learned about what I think is going on.

In the grand style of System V IPC in general, what programs allocate is not semaphores, but semaphore arrays (officially called 'semaphore sets'). A semaphore array has one or more actual semaphores (pretty much always one these days) and a unique semaphore identifier . In ipcs -s output, these are nsems (how many semaphores are in the array) and semid respectively.

The kernel.sem sysctl lets you set three different limits related to this:

• how many semaphore arrays can be allocated ( SEMMNI , the fourth field).
• how many semaphores can be allocated in total ( SEMMNS , the second field).
• how many semaphores can be in a single semaphore array ( SEMMLS , the first field).

(The third field has to do with the semop(2) system call.)

The limit you're most likely to run into is how many semaphore arrays can be allocated, which is a pretty low number (128, regardless of how much memory you have). I believe that bumping it up is pretty much completely harmless, especially as all the kernel uses this value for is to limit how many semaphore arrays can be in existence at once.

As a side note that's unlikely to ever be important, there's an undocumented hard limit of 32768 on SEMMNI ( IPCMNI , in include/linux/ipc.h ).

(For more details on all of this, see the proc(5) and semget(2) manpages. Unfortunately the proc manpage doesn't have a pointer to semget ; if it did, things would be much less confusing.)