== Documenting the _kernel.sem_ sysctl

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.)