Bug 403621 - ypserv excessive vsize
ypserv excessive vsize
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ypserv (Show other bugs)
5.0
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Honza Horak
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-28 18:03 EST by Ben Jarvis
Modified: 2013-02-12 17:49 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 00:53:09 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)
Core file from a large ypserv (12.07 MB, application/x-gzip)
2007-11-28 18:03 EST, Ben Jarvis
no flags Details
mudflap modified ypserv (196.68 KB, application/x-rpm)
2008-04-02 08:40 EDT, Vitezslav Crhonek
no flags Details
Patch removing invalid ypdb_close call (489 bytes, patch)
2010-01-26 12:31 EST, Karel Klíč
no flags Details | Diff

  None (edit)
Description Ben Jarvis 2007-11-28 18:03:29 EST
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.
Comment 1 Ben Jarvis 2007-11-28 18:03:30 EST
Created attachment 271911 [details]
Core file from a large ypserv
Comment 2 Chris Van Hoof 2007-12-11 19:37:19 EST
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
Comment 3 Ben Jarvis 2007-12-12 11:17:56 EST
This is on bare metal RHEL 5.0, no updates.
Comment 4 Chris Van Hoof 2007-12-12 17:53:53 EST
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
Comment 5 Chris Van Hoof 2007-12-12 17:55:20 EST
Ben,
One additional question, are the "various non-linux clients" by chance AIX clients?
Comment 6 Ben Jarvis 2007-12-12 18:17:25 EST
Yes, we have a few AIX machines running 5L and one running 6.1.

Comment 7 Chris Van Hoof 2007-12-12 19:38:25 EST
(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
Comment 8 Vitezslav Crhonek 2008-04-02 08:39:24 EDT
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!
Comment 9 Vitezslav Crhonek 2008-04-02 08:40:27 EDT
Created attachment 300054 [details]
mudflap modified ypserv
Comment 10 Vitezslav Crhonek 2008-05-06 11:43:49 EDT
Ping?
Comment 11 Chris Van Hoof 2008-05-06 11:58:02 EDT
(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
Comment 13 Karel Klíč 2010-01-26 12:31:32 EST
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.
Comment 17 RHEL Product and Program Management 2010-08-09 14:22:20 EDT
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.
Comment 20 RHEL Product and Program Management 2011-01-11 15:30:24 EST
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.
Comment 21 RHEL Product and Program Management 2011-01-12 10:24:58 EST
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.
Comment 22 RHEL Product and Program Management 2011-05-31 09:29:53 EDT
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.
Comment 23 Honza Horak 2011-08-15 04:37:49 EDT
(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.
Comment 24 Ben Jarvis 2011-08-15 11:05:53 EDT
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...
Comment 30 errata-xmlrpc 2012-02-21 00:53:09 EST
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

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