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.

Description of problem:

I would like to ask that https://bugzilla.redhat.com/show_bug.cgi?id=132608 be evaluated once more to solve long standing issues with multiple applications that are currently worked around either by restarting processes or various amounts of internal code wrangling.

The original fears from 2004 should be able to be avoided by using inotify where available and simply not having this feature (legacy mode) where not available.

Version-Release number of selected component (if applicable):

All since 2004

How reproducible:

Have a service that uses material from nsswitch and subsequently update the /etc/nsswitch.conf configuration and attempt to evaluate updated information.

Actual results:

Old information is returned

Expected results:

New information is returned

Previously suggested workaround using NSCD doesn't work nowadays, since SSSD is not compatible with it.

Red Hat Enterprise Linux 7 is going to enter Maintenance Support Phase 1 during 2019, and this change means that our customers are looking forward to a stable release without the kinds of changes that this auto-reloading might imply. The lead time to make this change is going to be quite long, we will have to enable this upstream, test it thoroughly for a time with various workloads (enabled by default), and then after enough experience decide if it's ready to backport to a stable RHEL release. All of this work rules out this change for RHEL 7, but we will continue this work as part of the RHEL 8 request in bug 132608. Therefore I'm closing this RFE in favour of bug 132608. Lastly, we understand that this kind of feature is important and will continue investigating how to best implement it upstream.

*** This bug has been marked as a duplicate of bug 132608 ***