Bug 452989 - pam_limits freeze with 100% CPU time
pam_limits freeze with 100% CPU time
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
5.2
i686 Linux
low Severity low
: rc
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-26 09:44 EDT by veliogluh
Modified: 2008-12-04 11:16 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-04 11:16:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description veliogluh 2008-06-26 09:44:40 EDT
We upgrade our two Red Hat 4.6 SSH (Terminal) server to RedHat5.2. Our users 
are stored in Active Directory. After the upgrade sometimes users login freezes 
(at pam session service) and the SSH process consumes 100% CPU. When I turned 
on SSH debug and pam_limits debug on, I see that the pam_limits process checks 
that is the user in a group then it hang ups. There is no problem with the 
other RedHat4 system. 

This problem is not for specific user or specific time. Sometimes happens.

Here is the normal pam_limits debug log:
Jun 26 15:31:18 hyperion sshd[8892]: pam_limits(sshd:session): reading settings 
from '/etc/security/limits.conf'
Jun 26 15:31:18 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users2
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users2
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group ila
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group ila
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): process_limit: 
processing - cpu 10 for GROUP
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): process_limit: 
processing soft nproc 24 for GROUP
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): process_limit: 
processing hard nproc 32 for GROUP
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): process_limit: 
processing - memlock 10000 for GROUP
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking if 
username is in group users
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): process_limit: 
processing - maxlogins 3 for GROUP
Jun 26 15:31:19 hyperion sshd[8892]: pam_limits(sshd:session): checking logins 
for 'username' (maximum of 3


And here is the log for a crashed login while consuming %100CPU:
Jun 26 15:13:55 hyperion sshd[8547]: pam_limits(sshd:session): reading settings 
from '/etc/security/limits.conf'
Jun 26 15:13:55 hyperion sshd[8547]: pam_limits(sshd:session): checking if 
username is in group users2

Then nothing until a kill the PID 8547

This problem comes with RedHat5 so it is probably about pam_limits.so module.
Comment 1 Tomas Mraz 2008-06-27 03:12:49 EDT
I suppose the problem is rather in some nsswitch module. What is in your
/etc/nsswitch.conf? Can you try to install debuginfo packages for pam, samba,
glibc, openssh and try to attach a gdb to the process which is consuming 100%
CPU and dump a backtrace?
Comment 2 Tomas Mraz 2008-12-04 11:16:08 EST
Unfortunately I cannot reproduce the problem and there is not enough information in this bug report to fix it.

Please contact our technical support http://www.redhat.com/support/ for issues with Red Hat Enterprise Linux.

Note You need to log in before you can comment on or make changes to this bug.