From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Description of problem: We have a group with 86 users. If we put in /etc/group an entry that is longer than 671 characters, that group is determined invalid. chgrp doesn't work, ls -l entries show only the uid(if the id is manually set). Our existing 7.3 boxes work fine with the entry Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create /etc/group entry that has 671 characters on the line. chgrp works fine. 2.Add one more character to make it 672. 3.chgrp breaks, saying invalid group name Additional info: Box does nightly up2date -u -f, so latest errata are always on the machine.
This is a glibc bug, AFAIR.
Can you try more recent glibc, such as glibc-2.3.1-5 from rawhide? Cannot reproduce it with glibc-2.3.1-2, even with 737 bytes long line in /etc/group. Also, are you using nscd or not?
I've started using the rpms from (I forget his name, but it's people.redhat.com/username, or something like that). It's glibc-2.3.1-2, and it eliminated the group problem, and also a mysql bug that was problematic on another system.
Wanted to let you know that I have the problem also when using NIS, i.e. 'compat' or the like in /etc/nsswitch.conf. I'm not using nscd. The suggested rawhide rpms fixes the problem, even lines longer than 900 characters work fine. Another update to the problem: Any group entries _after_ a line longer than 671 don't work as well. It isn't just the long entries themselves that break, all successive group entries will have the same problem. (I hope this will be fixed soon, as we have 367 group entries in NIS longer than 671 characters.)
*** Bug 77156 has been marked as a duplicate of this bug. ***
After reducing the line lengths in /etc/group to less than 671 characters, I've come to the conclusion that this problem isn't as easy as first reported. The filegroup handling in glibc-2.2.93-5 is seriously crippled. It breaks when confronted with large group entries and/or groups with many members. I've been unable to discover any hard limits of the two conditions that seem to be causing trouble: 1) number of characters in the entry, and 2) number of members. Example: 1. Create a group 'test1234' with a 3-digit GID (in my test-case, the GID was 400) and 77 members, where each member's username is 8 characters long. This works fine, even though the line is 708 characters long. Add one more member, and it breaks. 2. Replace the 77 8-character members with 112 members whose usernames are 4 characters long. This line is 575 characters long, and it doesn't work anymore. Remove one member, and it will work fine. 3. Repeat step 2, but put in 3-character usernames. Now, we're allowed to have 125 members, and the line is 519 characters long. Add one more member, and it breaks. There seems to be a connection between the number of characters in the group line and the number of members. As stated before, it's not only the "offending" group entries that don't work. Any entries after one such entry have the same problem. Remove the troublemaker, and the rest won't have problems. We have several thousands groups, and we've reduced the problem somewhat by dividing the groups into separate entries with the same GID but with a different name, a method we've used for years to overcome similar limitations in other operating systems as well as NIS. We'll probably have to reduce the line length to less than 640 to get rid of the problem entirely, and then it's starting to get painful...
A somewhat related issue: when you have multiple groups with same GID in NIS then on RHL8.0 no group name is shown for those groups with 'id', just the GID. Earlier versions do show the name of the (first?) group in such cases. Upgrading to rawhide glibc (version 2.3.1-32 tested) fixes it.
Is bug 4289 a dup of this one?
The problem I had, with NIS groups being to long, went away with the latest glibc errata. Are the rest of the issues solved as well?