[Bug 206927] Bad semaphore return code on collision

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206927

            Bug ID: 206927
           Summary: Bad semaphore return code on collision
           Product: Base System
           Version: 10.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: karl at denninger.net

Attempting to upgrade Postgres from 9.4.5 to 9.5.0 I ran into the following
error:

$ initdb -D data-default
...
creating template1 database in data-default/base/1 ... FATAL:  could not
create semaphores: Invalid argument
DETAIL:  Failed system call was semget(2, 17, 03600).

This appears to be an incorrect return; semaphore key "2" is indeed in use but
by a different, unrelated process (the web server.)


This is what Tom Lane from Postgres had to say about their code, which appears
to make sense:

******************** from postgres mailing list ***************

Hmm.  On my Linux box, "man semget" says EINVAL means

       EINVAL nsems  is less than 0 or greater than the limit on the number of
              semaphores per semaphore set (SEMMSL), or a semaphore set corre-
              sponding  to  key  already  exists, and nsems is larger than the
              number of semaphores in that set.

which agrees with the POSIX spec.  Is FreeBSD the same?

Proceeding on the assumption that it is ...

17 is the same nsems value we've been using for donkey's years, so the
SEMMSL aspect of this seems unlikely to apply; what presumably is
happening is a collision with an existing semaphore's key.  Our code is
prepared for that, but it expects a different error code in such cases,
either EEXIST or EACCES:

        /*
         * Fail quietly if error indicates a collision with existing set. One
         * would expect EEXIST, given that we said IPC_EXCL, but perhaps we
         * could get a permission violation instead?  Also, EIDRM might occur
         * if an old set is slated for destruction but not gone yet.
         */

It sounds like your kernel is returning EINVAL in preference to any of
those codes, which would be pretty broken.  I do not want to make our code
treat EINVAL as meaning we should retry with a different key, because if
the problem is indeed the SEMMSL limit, we'd be in an infinite loop.

You can probably get past this for the moment if you can remove the
semaphore set with key 2, but I'd advise filing a FreeBSD kernel
bug about their choice of errno.

********** end ***********

Indeed our (FreeBSD) man page says:

     The semget() system call will fail if:

     [EACCES]           Access permission failure.

     [EEXIST]           IPC_CREAT and IPC_EXCL were specified, and a semaphore
                        set corresponding to key already exists.

     [EINVAL]           The number of semaphores requested exceeds the system
                        imposed maximum per set.

     [ENOSPC]           Insufficiently many semaphores are available.

     [ENOSPC]           The kernel could not allocate a struct semid_ds.

     [ENOENT]           No semaphore set was found corresponding to key, and
                        IPC_CREAT was not specified.

EINVAL is an incorrect return under this circumstance; EEXIST appears to be the
expected returned error code.

-- 
You are receiving this mail because:
You are the assignee for the bug.