Bug 76618

Summary:	ypserv file handle caching code causes map files to remain locked even when not in use
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <mpusalkar>
Component:	ypserv	Assignee:	Alexander Larsson <alexl>
Status:	CLOSED RAWHIDE	QA Contact:	Jay Turner <jturner>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3	CC:	mpusalkar, notting, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-11-04 17:00:53 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:

Description Need Real Name 2002-10-24 08:43:38 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0

Description of problem:
With the new ypserv file handle caching code in "yp_db.c" since version 2.x,
which comes with Redhat 7.3 and above the maps are not closed till ypserv is
stopped. This results in the map files remaining locked once a ypcat or a
similar command is issued. Event though the ypcat command completes the map
files remain locked.
  Due to this other programs (such as ours) which try to open the map files fail
as they are unable to acquire the file lock while calling "gdbm_open". 
  Though it may not be possible for performance reasons to dump the file handle
caching code, there definitely must be a way to disable file handle caching.
   Though the "ypserv.conf" file has a "files: <num>" setting by which one would
assume that if we set the <num> value to 0, no file handles would be cached,
this does not seem to work.
   Looking at the code it seems that the value read from the "ypserv.conf" file
is read into a variable "cached_filehandles" but is then just discarded. Instead
a hardcoded value of 30 is used via a macro for MAX_FOPEN.
   There should be atleast be a way to disable file handle caching if the locks
cant be released.
  This issue does not exist with Redhat 7.2 which uses ypserv 1.3.x.

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


How reproducible:
Always

Steps to Reproduce:
1.Configure NIS and start ypserv and start ypbind to bind to this ypserv run the
ypserv in debug mode.
2.run ypcat passwd.byname ( with the maps already populated )
3. cat /proc/locks shows the FLOCK (READ lock) being retained by ypserv even
though ypcat has completed.
	

Actual Results:  The cat command above shows FLOCK (READ lock) being retained by
ypserv even though the debug log shows "ypdb_close() called". ( This actually
doesnt call the actual "gdbm_close()" due to file handle caching)

Expected Results:  The FLOCK should have been cleared upon the ypdb_close() or
the file handle caching should be configurable via the "ypserv.conf" files: setting

Additional info:

Comment 1 Alexander Larsson 2002-10-24 11:29:03 UTC

Yeah. Disabling it should work. I dunno if it is safe to drop the lock in
ypdb_close() though. I will look into it.

Comment 2 Need Real Name 2002-10-25 04:19:58 UTC

We have our product that is on the verge of shipping. Our product works fine
with Redhat versions 7.2 or lower as of now.
  It would be very helpful if you could just give an update of the ypserv
package for Redhat 7.3 and 8.0 which would have a mechanism of disabling file
handle caching.
  That would be enough for our purposes. It would be very helpful if you could
provide this patch as soon as possible.

Comment 3 Alexander Larsson 2002-10-25 07:29:15 UTC

It's unfortunately worse than that. There has been a recent security-related
memory leak in ypserv, and the errata for 7.x include updating to a recent ypserv.
See: http://rhn.redhat.com/errata/RHSA-2002-223.html

This means you'll have problems on updated 7.2 (etc) machines too. I'll try to
take a look at this as soon as I can.

We don't normally do bugfix erratas for old releases (except for really major
bugs). But at I can produce a patch that you could use and fix it for later RH
releases.

Comment 4 Need Real Name 2002-10-28 07:07:39 UTC

We will eagering wait for your fix.
  Thanx for your prompt responses.

Comment 5 Need Real Name 2002-10-28 07:08:36 UTC

Read "eagering" as "eagerly" !!

Comment 6 Alexander Larsson 2002-10-30 02:06:36 UTC

I've spoken with the ypserv maintainer. Expect a patch that disables caching if
files == 0.

Comment 7 Alexander Larsson 2002-11-04 16:29:56 UTC

Sorry for the delay. I've been on a meeting the whole last week.
I'll take a look at it this week.

Comment 8 Alexander Larsson 2002-11-04 17:00:45 UTC

It is fixed in ypserv 2.6, availible at:
ftp://ftp.kernel.org/pub/linux/utils/net/NIS/

I will build a package in rawhide tomorrow. You can extract a patch from the
release if you need it.

Comment 9 Alexander Larsson 2002-11-05 09:27:29 UTC

I have now built ypserv 2.6 in our system, and it will reach rawhide in a day or
so. It should fix your problems (i.e. files=0 will disable caching), and the
rawhide package should work on a 8.0 system. If you want to build packages for
7.x the errata ypserv 2.5 package should be a good basis, since 2.5 and 2.6 have
few differences.

Comment 10 Need Real Name 2002-11-12 05:36:28 UTC

I will try this out.

Comment 11 Need Real Name 2002-11-12 07:01:57 UTC

Could you let me know the URL where i can find the rawhide packages ? I looked
at the ftp.redhat.com site under the .../rawhide/... directory and could not
find a ypserv RPM

Comment 12 Alexander Larsson 2002-11-12 07:23:16 UTC

ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/ypserv-2.6-1.i386.rpm

Comment 13 Need Real Name 2002-11-13 03:56:50 UTC

I am unable to access the RPM with the URL you have given. Could you please
check whether the URL is accessable ?

Comment 14 Alexander Larsson 2002-11-13 08:39:20 UTC

It seems broken in some way. It may be on a mirror somewhere, but anyway i put a
copy at: http://people.redhat.com/alexl/RPMS/

Comment 15 Need Real Name 2002-11-15 08:55:37 UTC

I have verified this fix. It is working fine. 
If you could just get the URL for download fixed we can consider this issue closed.

Thanks for your help !!

Comment 16 Alexander Larsson 2002-11-15 09:30:27 UTC

Hmm. The ypserv package seems to have disappeared from rawhide completely now...

notting: Do you have any idea what happened to it?

Comment 17 Bill Nottingham 2002-11-15 19:31:13 UTC

It's getting pulled into trees, probably a transient push script error.

Comment 18 Alexander Larsson 2002-11-18 11:04:15 UTC

Nah. It was once there. But got removed somehow.

Comment 19 Need Real Name 2002-11-20 10:23:54 UTC

So when is link going to be up !! We need to provide this link since it doesn't
seem to be appropriate asking people to download from "people.redhat.com" !!

Comment 20 Alexander Larsson 2002-11-20 11:08:37 UTC

There was some sort of problem pushing the latest rawhide packages to the ftp
site. The upload died after having removed the old files. I think this has been
fixed now though, at least the file is there now.

Note that Rawhide itself is a transient entity. It always contains only the
latest packages in development. If I do e.g. a bugfix that is scheduled to be in
the next release it's gonna end up in rawhide as e.g. ypserv-2.6-2, and the old
one (ypserv-2.6-1) will disappear.

Comment 21 Need Real Name 2002-11-21 12:26:09 UTC

I verified that the links are working now. We will provide appropriate
instructions for downloading latest versions of ypserv.
  This issue is closed from our side.
Thanks !!