From owner-freebsd-bugs@freebsd.org Thu Feb 4 18:38:30 2016 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A4B4A9B58D for ; Thu, 4 Feb 2016 18:38:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B6F01DEE for ; Thu, 4 Feb 2016 18:38:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u14IcUQP001232 for ; Thu, 4 Feb 2016 18:38:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 206927] Bad semaphore return code on collision Date: Thu, 04 Feb 2016 18:38:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 18:38:30 -0000 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.=