RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1464049 - Idle nss file descriptors should be closed
Summary: Idle nss file descriptors should be closed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.4
Hardware: All
OS: All
urgent
urgent
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Amith
URL:
Whiteboard:
Depends On:
Blocks: 1478250
TreeView+ depends on / blocked
 
Reported: 2017-06-22 10:42 UTC by Amith
Modified: 2020-05-02 18:44 UTC (History)
11 users (show)

Fixed In Version: sssd-1.16.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1478250 (view as bug list)
Environment:
Last Closed: 2018-04-10 17:13:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
SSSD NSS log file (263.03 KB, text/plain)
2017-06-22 10:42 UTC, Amith
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4475 0 None closed Idle nss file descriptors should be closed 2020-08-12 19:59:27 UTC
Red Hat Product Errata RHEA-2018:0929 0 None None None 2018-04-10 17:15:43 UTC

Description Amith 2017-06-22 10:42:04 UTC
Created attachment 1290646 [details]
SSSD NSS log file

Description of problem:
When client_idle_timeout is set in SSSD.CONF, sssd should check for and terminate idle connections. See BZ827036. However, i see a minimum of four file descriptors active even when a user is inactive for a long time.

This behaviour has caused failures in our automated regression run. 

Version-Release number of selected component (if applicable):
sssd-1.15.2-49.el7.x86_64

Steps to Reproduce:
1. Setup sssd.conf as follows:

[sssd]
config_file_version = 2
domains = LDAP
services = nss, pam

[nss]
debug_level = 0xFFF0
client_idle_timeout = 30

[pam]
debug_level = 0xFFF0
client_idle_timeout = 30

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
debug_level = 0xFFF0
cache_credentials = FALSE
ldap_uri = ldaps://hubcap.lab.eng.pnq.redhat.com
ldap_tls_cacert = /etc/openldap/certs/cacert.asc
ldap_search_base = dc=example,dc=com

2. login as ldap user and do nothing for 1 minute.

3. Open a new terminal and monitor the number of NSS and PAM file descriptors.

# lsof -p $(pidof sssd_nss) | grep /var/lib/sss/pipes/nss
sssd_nss 4663 root   17u     unix 0xffff88b53b7ff800       0t0   40687 /var/lib/sss/pipes/nss
sssd_nss 4663 root   21u     unix 0xffff88b539489000       0t0   41481 /var/lib/sss/pipes/nss
sssd_nss 4663 root   22u     unix 0xffff88b53868a000       0t0   41913 /var/lib/sss/pipes/nss
sssd_nss 4663 root   23u     unix 0xffff88b539977000       0t0   41683 /var/lib/sss/pipes/nss
sssd_nss 4663 root   24u     unix 0xffff88b538688c00       0t0   41794 /var/lib/sss/pipes/nss

# lsof -p $(pidof sssd_pam) | grep /var/lib/sss/pipes/pam
sssd_pam 4664 root    0u     unix 0xffff88b538a03000       0t0   41454 /var/lib/sss/pipes/pam
sssd_pam 4664 root   20u     unix 0xffff88b51f013400       0t0   42210 /var/lib/sss/pipes/pam


Actual results:
After 30 seconds, sssd should terminate idle FD's however that's not happening.

Expected results:
SSSD should kill idle connections once client_idle_timeout is over.

Additional info:

Comment 5 Lukas Slebodnik 2017-07-10 21:07:59 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3448

Comment 7 Lukas Slebodnik 2017-07-21 17:44:50 UTC
master:
* 74e2415f00d0cb27ae935c7d81aaf15d906cc927
* d24335e9bd611e6626a57da28ad8ed621bb473c1
* 422217c7ea5fbe94b386c93c19e2c1928151faa0

Comment 12 Amith 2017-11-28 17:06:14 UTC
Verified the bug on SSSD Version : sssd-1.16.0-6.el7.x86_64

Steps followed during verification:

1. Setup sssd.conf as mentioned in the bug description.

2. login as ldap user in SSSD client machine and wait for over a minute.

# ssh -l testuser1 localhost
testuser1@localhost's password: 
/usr/bin/id: cannot find name for group ID 2121
[testuser1@bkr-hv03-guest12 ~]$ 

3. Monitor NSS and PAM file descriptors on a different terminal.

With the latest sssd build, the count of FD's has come down to one. Earlier we use to see more than 2 idle connections, even after the client_idle_timeout (30 sec) was over.

[root@bkr-hv03-guest12 ~]# lsof -p $(pidof sssd_pam) | grep /var/lib/sss/pipes/pam
sssd_pam 24118 root    0u     unix 0xffff996ca17f4800       0t0    45146 /var/lib/sss/pipes/pam
[root@bkr-hv03-guest12 ~]# 
[root@bkr-hv03-guest12 ~]# lsof -p $(pidof sssd_nss) | grep /var/lib/sss/pipes/nss
sssd_nss 24117 root   17u     unix 0xffff996cb0b2d000       0t0    45180 /var/lib/sss/pipes/nss

Comment 15 errata-xmlrpc 2018-04-10 17:13:24 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0929


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