Jan Zelený <jzeleny(a)redhat.com> writes:
> After further consulation on IRC, I finally found the bug and fixed
> it. Sending patches in attachment.
Hello Jan,
I'm happy to report that this updated version of the memberof patch
passes all tests during 'make check'.
Yes, that was my original reference test.
However, when used in a real environment, it works with small groups
but
has problems with larger groups. I tried running 'getent group
somegroup' for different groups, and found that groups with more than
~1000 members aren't handled properly:
* 'getent group somegroup' never returns anything
* 'id someuser' hangs indefinately for some users. This seems to
happen if the user is a member of one or more large groups. The
limit for "large group" seems to be higher in this case though.
* 'id -G someuser' works for any user.
Another observation: sssd_be can't be killed by anything but a SIGKILL,
if any of the above problems have occured. When in this state, sssd_be
doesn't consume CPU. When issuing 'getent group largegroup' sssd_be
starts consuming CPU as expected, then abruptly stops using CPU and
enters the unkillable state.
As you described it, it looks like issue similar to what Stephen found earlier
and is now fixed. It probably isn't caused by the size of groups but rather
membership structure. Could you be more specific how the structure is
organized? Do you use rfc2307 or rfc2307bis? If the latter is the case, how
deep your membership structure goes and how does it approximately look like?
Anyway I will run some tests and see if I can reproduce the issue somehow.
Jan