Description of problem: When the password file is big, and disable_user_list is false, gdm-simple-greeter uses 100% CPU for several minutes after startup
Version-Release number of selected component (if applicable): 2.28.2-5.el6.x86_64
How reproducible: 100%
Steps to Reproduce:
1. Use large password file
2. boot machine
3. watch gdm-simple-greeter hogging CPU
Actual results: gdm-simple-greeter hogs CPU
Expected results: CPU available for useful things
1) Setting disable_user_list to true (I had to search quite a bit to find that one) avoids the issue.
2) This could be related to https://bugzilla.redhat.com/show_bug.cgi?id=598145
3) Numbers: processing a ~22k password file takes 5 minutes :(
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Just an update here.
Jon has done considerable work making this quite fast upstream.
We should rebase to pull this in. Otherwise we're going to have a bunch of pointless patches in cvs that will make maintainability more difficult. The gnome-2-30 branch is all minor bugfixes and translation updates.
Reproducer in #c0, giving qa_ack.
*** Bug 598145 has been marked as a duplicate of this bug. ***
Should be good to go.
In beta 2 the time it takes for the simple-greeter is ok now. But the gdm-user-switch-applet still needs 1:45, and during that time I don't get the gnome-panel. I admit that the time has decreased significantly, but it is still quite long. And together with https://bugzilla.redhat.com/show_bug.cgi?id=610233 this becomes painful...
Please file a new bug for that. Can you attach gdb to the user switch applet during this time and interrupt it a few times to see where it is spending time? Thanks.
Tested with >40k password file on gdm-2.30.4-21.el6.x86_64. No CPU hogging. Moving to VERIFIED.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.