Date: Thu, 04 Feb 2016 18:38:30 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 206927] Bad semaphore return code on collision Message-ID: <bug-206927-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206927 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@FreeBSD.org Reporter: karl@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 appe= ars 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 cor= re- 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. O= ne * would expect EEXIST, given that we said IPC_EXCL, but perhaps we * could get a permission violation instead? Also, EIDRM might occ= ur * 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 semaph= ore set corresponding to key already exists. [EINVAL] The number of semaphores requested exceeds the syst= em 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206927-8>