getgrgid returns nothing for some valid gid

[John Benjamins]

Hi,

Trying to write a perl script and have run into some weirdness with getgrgid. The shortest script that reproduces the problem is the following:

# perl -e 'print scalar(getgrgid(149)), "\n"'
elp
# perl -e 'print scalar(getgrgid(150)), "\n"'
# perl -e 'print scalar(getgrgid(151)), "\n"'
mmw

And yes, gid 150 is a valid group. Is pwgrd the culprit here? There are about 3 or 4 other valid group id's that also return nothing, but that list is not always constant(!). We are running B.11.23 U ia64. One thing to note is that we have very large groups memberships lists. We have had to create multiple lines in /etc/group with the same name/gid to get all the users in the same groups. This was happening last week, and over the weekend the system was rebooted , but still displays the same problem (i.e. a restart of pwgrd does not seem to have fixed this).

Any help is appreciated.

Thanks,
John

[James R. Ferguson]

Hi John:

The fact that you have had to create multiple lines in '/etc/group' with the same name/gid to get all the users in the same groups may be the reason for this behavior.

That said, however, at of 11.0 there was no good reason to have to populate '/etc/group' in the fashion that you describe. If '/etc/logingroup' and '/etc/group' are links to the same file, the default access list includes the entire set of groups associated with the user.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) John:

Interestingly, I have an AIX (release 5.2)server with a vast number of users belonging to the same group. Like your case, the declaration of the group name is replicated. Using Perl (5.8.0) as you show, also fails for me in the case described.

Regards!

...JRF...

[James R. Ferguson]

Hi John:

I also suspect that:

# perl -le 'print scalar getgrnam("gidname")'

...where 'gidname' is the correct string for group-150 in your case, will *not* return the value '150'...

Regards!

...JRF...

[John Benjamins]

Hi James,

You are correct in that

perl -le 'print scalar getgrnam("gidname")'

also fails for these groups. One thing I should clarify, although we have multiline groups, none of the groups that display this problem are like that, although they are between 1479 and 1527 in length.

Thanks!
John

[A. Clay Stephenson]

Are you running NIS? If so, the maximum map entry length does impose limits and in your case only the first entry of any identical group entry would actually be mapped. You could try kill pwgrd and see if that fixes you; UNIX boxes ran for decades without pwgrd and yours will too.

[John Benjamins]

No, we are not running NIS. pwgrd is the prime suspect here. However, immediately after a system restart over the weekend, we still saw this behaviour. So restarting pwgrd does not clear the issue. However, I don't think we want to just turn off pwgrd either. Looking at pwgr_stat we are averaging about 30 getpwuid calls/second and about 6 getgrgid calls/second (with a lot fewer getpwnam/getgrnam calls). So getting rid of the caching daemon may have a performance impact, but maybe not enough to make a difference. However, having pwgrd return nothing for certain groups may be more of a performance issue.

Thanks,
John