The munin rpms from EPEL failed to install correctly on a particular machine. This is why
# /usr/sbin/groupadd -r munin groupadd: Can't get unique system GID (no more available GIDs) #
but I don't understand why this happens. Even after checking the man pages for groupadd and login.defs, I have been unable to determine what the settings for SYS_GID_MIN/SYS_GID_MAX on RHEL/CentOS are. None of the 5/6 machines I have access to list them in login.defs. Even assuming relatively conservative values of 201/499, resp. (examples from other distros include 101/999), this doesn't add up.
# grep munin /etc/group # ypmatch munin group # wc -l /etc/group 100 /etc/group # grep SYS_GID /etc/login.defs #
Any ideas? Information seems to be pretty thin on the ground.
The groupadd manpage gives this clue:
The default is to use the smallest ID value greater than or equal to GID_MIN and greater than every other group.
Maybe you have a group numbered GID_MAX or more already? 60000, according to the manpage.
On Wed, Sep 02, 2015 at 09:42:29PM +0100, isdtor wrote:
The munin rpms from EPEL failed to install correctly on a particular machine. This is why
# /usr/sbin/groupadd -r munin groupadd: Can't get unique system GID (no more available GIDs) #
but I don't understand why this happens. Even after checking the man pages for groupadd and login.defs, I have been unable to determine what the settings for SYS_GID_MIN/SYS_GID_MAX on RHEL/CentOS are. None of the 5/6 machines I have access to list them in login.defs. Even assuming relatively conservative values of 201/499, resp. (examples from other distros include 101/999), this doesn't add up.
# grep munin /etc/group # ypmatch munin group # wc -l /etc/group 100 /etc/group # grep SYS_GID /etc/login.defs #
Any ideas? Information seems to be pretty thin on the ground.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea.
On Wed, Sep 02, 2015 at 02:19:51PM -0700, Greg Lindahl wrote:
The groupadd manpage gives this clue:
The default is to use the smallest ID value greater than or equal to GID_MIN and greater than every other group.
Maybe you have a group numbered GID_MAX or more already? 60000, according to the manpage.
On Wed, Sep 02, 2015 at 09:42:29PM +0100, isdtor wrote:
The munin rpms from EPEL failed to install correctly on a particular machine. This is why
# /usr/sbin/groupadd -r munin groupadd: Can't get unique system GID (no more available GIDs) #
but I don't understand why this happens. Even after checking the man pages for groupadd and login.defs, I have been unable to determine what the settings for SYS_GID_MIN/SYS_GID_MAX on RHEL/CentOS are. None of the 5/6 machines I have access to list them in login.defs. Even assuming relatively conservative values of 201/499, resp. (examples from other distros include 101/999), this doesn't add up.
# grep munin /etc/group # ypmatch munin group # wc -l /etc/group 100 /etc/group # grep SYS_GID /etc/login.defs #
Any ideas? Information seems to be pretty thin on the ground.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 02/09/2015, Greg Lindahl lindahl@pbm.com wrote:
Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea.
This is not exactly trivial to figure when there's no documentation what the system group limits actually are. There's a very indirect mention in the same man page, "Values between 0 and 999 are typically reserved for system accounts.", but I bet that's just the usual case of generic documentation not tailored to the distribution.
The highest id in the group file is 499. Combined with the error, this could be consistent with a SYS_GID_MAX of 499. But no ids between 189 and 485 have been assigned at all. Is groupadd really this limited?
Am 03.09.2015 um 10:33 schrieb isdtor isdtor@gmail.com:
On 02/09/2015, Greg Lindahl lindahl@pbm.com wrote:
Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea.
This is not exactly trivial to figure when there's no documentation what the system group limits actually are. There's a very indirect mention in the same man page, "Values between 0 and 999 are typically reserved for system accounts.", but I bet that's just the usual case of generic documentation not tailored to the distribution.
The highest id in the group file is 499. Combined with the error, this could be consistent with a SYS_GID_MAX of 499. But no ids between 189 and 485 have been assigned at all. Is groupadd really this limited?
there exist a distinction between normal and system accounts/groups. For example: everything under 499 are system accounts (e.g. daemons) and 500 is your first user account ...
-- LF
On 09/03/2015 01:07 PM, Leon Fauster wrote:
Am 03.09.2015 um 10:33 schrieb isdtor isdtor@gmail.com:
On 02/09/2015, Greg Lindahl lindahl@pbm.com wrote:
Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea.
This is not exactly trivial to figure when there's no documentation what the system group limits actually are. There's a very indirect mention in the same man page, "Values between 0 and 999 are typically reserved for system accounts.", but I bet that's just the usual case of generic documentation not tailored to the distribution.
The highest id in the group file is 499. Combined with the error, this could be consistent with a SYS_GID_MAX of 499. But no ids between 189 and 485 have been assigned at all. Is groupadd really this limited?
look at -g in the manpage: "the default is to use [...] and greater than every other group." So I guess if SYS_GID_MAX==499 and you already have a group 499, you may need to use -g. Create the group with -g, then try to install your rpm (I think that's what you were doing?) and hopefully it will see that a group with the correct name already exists and proceed normally.
On 09/03/15 04:33, isdtor wrote:
On 02/09/2015, Greg Lindahl lindahl@pbm.com wrote:
Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea.
This is not exactly trivial to figure when there's no documentation what the system group limits actually are. There's a very indirect mention in the same man page, "Values between 0 and 999 are typically reserved for system accounts.", but I bet that's just the usual case of generic documentation not tailored to the distribution.
GIDs < 1000 have been std in all Unices for a long, long time. For an ordinary user, going above shouldn't be a problem. <chuckles> At work, a couple of years ago, we went to 7-digit user & gids. <snip> mark
On Thu, Sep 03, 2015 at 07:58:30AM -0400, mark wrote:
GIDs < 1000 have been std in all Unices for a long, long time. For an ordinary user, going above shouldn't be a problem. <chuckles> At work, a couple of years ago, we went to 7-digit user & gids.
<snip>
We have 8 and 9 digit UIDs now, however some software still chokes on such long UIDs.
-
Greg Lindahl -
isdtor -
Jonathan Billings -
Leon Fauster -
mark -
Nicolas Thierry-Mieg