Bug #9600
closedsysconf(_SC_GETGR_R_SIZE_MAX) is just a hint for getgrnam_r()
Description
When there is a group that has a lot of members, TestProcess#test_execopts_gid fails. Following is a more simple example:
$ ruby -e 'system("true", gid: "largegroup")'
-e:1:in `system': Numerical result out of range - getgrnam_r (Errno::ERANGE)
from -e:1:in `<main>'
This wrong exception happens because obj2gid() in process.c calls getgrnam_r() with a buffer that was allocated based on the size returned by sysconf(_SC_GETGR_R_SIZE_MAX). In Linux, sysconf(_SC_GETGR_R_SIZE_MAX) returns 1024, but actually this value is just a hint, so obj2gid() should gradually extend the buffer until getgrnam_r() no longer throws ERANGE.
The same issue was reported in the following page:
http://tomlee.co/2012/10/problems-with-large-linux-unix-groups-and-getgrgid_r-getgrnam_r/
Updated by nobu (Nobuyoshi Nakada) about 11 years ago
Isn't there any way to get the real number?
Updated by naruse (Yui NARUSE) about 11 years ago
Rei Odaira wrote:
but actually this value is just a hint, so obj2gid() should gradually extend the buffer until getgrnam_r() no longer throws ERANGE.
SuSv7 changes it.
- http://pubs.opengroup.org/onlinepubs/009695399/functions/getgrnam.html v6's getgrnam_r
- http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrnam.html v7's getgrnam_r
- http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html v7's sysconf
SD5-XSH-ERN-166 is applied, changing "Maximum size" to "Initial size" for the "Maximum size of ..." entries in the table in the DESCRIPTION.
But I didn't find SD5-XSH-ERN-166 itself.
Updated by akr (Akira Tanaka) about 11 years ago
Off topic.
Yui NARUSE wrote:
SuSv7 changes it.
There is no Single Unix Specification version 7 (yet).
The issue number is not the version number.
SUSv3:
| The Single UNIX Specification, Version 3 is made up of the Base Specifications, Issue 6 and
| X/Open Curses, Issue 4, Version 2.
http://www.unix.org/version3/sus_contents.html
SUSv4:
| The Single UNIX Specification uses The Open Group Base Specifications, Issue 7 documentation as its core.
| The documentation is structured as follows:
| * The Base Specifications, Issue 7, composed of:
| - Base Definitions, Issue 7 (XBD7)
| - System Interfaces, Issue 7 (XSH7)
| - Shell and Utilities, Issue 7 (XCU7)
| - Rationale, Issue 7, (XRAT7) (Informative)
| * X/Open Curses, Issue 7
http://www.unix.org/version4/overview.html
Updated by djberg96 (Daniel Berger) about 11 years ago
I don't think there's a way to get it. You'll have to rescue and retry with a realloc'ed buffer.
One bit of trickiness is that different platforms seem to set errno to different values on different platforms. In my own sys-admin gem, I caught Errno::ERANGE on Linux and Solaris, while on Darwin it was Errno::ENOENT, and on FreeBSD it was Errno::ENOTTY.
Updated by nobu (Nobuyoshi Nakada) about 11 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Applied in changeset r45290.
process.c: expand buffer on ERANGE
- process.c (obj2uid, obj2gid): now getpwnam_r() and getgrnam_r()
may need larger buffers than sysconf values, so retry with
expanding the buffer when ERANGE is returned.
[ruby-core:61325] [Bug #9600]
Updated by ReiOdaira (Rei Odaira) about 11 years ago
Wouldn't it be possible to backport this to 2.0.0 and 2.1, where the same issue resides?
Updated by naruse (Yui NARUSE) about 11 years ago
- Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED
Updated by nagachika (Tomoyuki Chikanaga) almost 11 years ago
- Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONE
r45287, r45288, r45289 and r45290 were backported into ruby_2_1
branch at r46449.
Updated by usa (Usaku NAKAMURA) almost 11 years ago
- Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONE to 1.9.3: REQUIRED, 2.0.0: DONE, 2.1: DONE
backported into ruby_2_0_0
at r46511.