Bug 403621
| Summary: | ypserv excessive vsize | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Ben Jarvis <ben.jarvis> | ||||||||
| Component: | ypserv | Assignee: | Honza Horak <hhorak> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-daemons | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 5.0 | CC: | azelinka, jbastian, pbat, psklenar, rvokal, steved, tao | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-02-21 05:53:09 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 271911 [details]
Core file from a large ypserv
Ben, Are you running this on bare metal h/w or in a virtual instance? I have a case that I have been working on that looks really similar, but running on RHEL 4.5 virtual machine. --chris This is on bare metal RHEL 5.0, no updates. Ben, Thanks for the info -- I'm working this on my end right now. Once we come to some conclusion (or have some decent info), i'll be sure to share that with you. Regards, Chris Ben, One additional question, are the "various non-linux clients" by chance AIX clients? Yes, we have a few AIX machines running 5L and one running 6.1. (In reply to comment #6) > Yes, we have a few AIX machines running 5L and one running 6.1. > > Thanks Ben, same situation here, only we find that this seems to be the AIX clients who trigger this to occur... Other ypserv instances that talk only to Linux clients (with identical configuration) do not have have this issue. I'll be in touch. --chris Ben, we would like to gather mudflap output, please: a) install libmudflap-devel package b) build and install modified ypserv and run it c) connect only AIX clients Let me know if you have any questions. Thanks in advance! Created attachment 300054 [details]
mudflap modified ypserv
Ping? (In reply to comment #6) > Yes, we have a few AIX machines running 5L and one running 6.1. > > Hi Ben -- Any chance you've been able to reproduce this running the instumented packages Vitezslav built for you? --chris Created attachment 386884 [details]
Patch removing invalid ypdb_close call
This bug seems to be related to requesting NIS maps that do not exist.
I found an error in a relevant part of the code, which probably causes it.
The invalid code "ypdb_close(NULL)" is called when an request for transferring a new map comes to ypserv, and the map is not coming from trusted master ypserver.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. (In reply to comment #14) > Test packages with the patch from comment 13 are available at > http://download.devel.redhat.com/brewroot/packages/ypserv/2.19/5.el5.IT396643/ Ben, if you still encounter this issue, is it possible to test the build above? ypserv will be probably updated in RHEL-5.8, so this issue could be possibly fix too. We have not seen this issue recur for a few years. I did go through and disable all the NIS maps we did not need on the client end to avoid log spam about missing maps, sounds like maybe I unwittingly worked around the problem by doing so... 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. http://rhn.redhat.com/errata/RHBA-2012-0205.html |
Description of problem: ypserv fails to respond to NIS queries, printing the following in syslog: Nov 26 02:06:00 summit ypserv[13978]: WARNING(ypproc_all_2_svc): cannot fork: Ca nnot allocate memory The ypserv process virtual memory size grows to many gigabytes. Resident memory usage remains a nominal 10-20mb. Once it occurs, the problem persists until ypserv is restarted. The syslog is also filled with error messages such as the following: Nov 25 11:34:00 summit ypserv[13978]: refused connect from 10.65.11.83:701 to procedure ypproc_match (mn.quantum.com,project.byname;-4) These messages are legitimate. We have various non-linux clients that request NIS maps that do not exist, in this case project.byname, and this error gets put in syslog whenever that happens. Version-Release number of selected component (if applicable): ypserv-2.19-3 [from RHEL5 AS w/o updates] How reproducible: Occurs consistently within a few days on our NIS server. I have not been able to reproduce it on demand. The vsize increase is a rapid event that occurs irregularly, not a gradual 'leak'. It will be 10-20mb for days, then increase by many gigabytes over the course of a couple minutes. It seems to happen most frequently during our nightly AMANDA backups. I have a core file of a large ypserv. I'm happy to try anything suggested in an effort to make a compact test case. Steps to Reproduce: 1. 2. 3. Actual results: ypserv virtual memory footprint grows until it cannot be forked. Expected results: ypserv remains a small size. Additional info: Current work-around is to run 'service ypserv restart' regularly. Core file collected from such a large ypserv attached.