Bug 76618 - ypserv file handle caching code causes map files to remain locked even when not in use
ypserv file handle caching code causes map files to remain locked even when n...
Product: Red Hat Linux
Classification: Retired
Component: ypserv (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alexander Larsson
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2002-10-24 04:43 EDT by Need Real Name
Modified: 2015-01-07 19:01 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-04 12:00:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-10-24 04:43:38 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823

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:

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 07:29:03 EDT
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 00:19:58 EDT
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 03:29:15 EDT
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
Comment 4 Need Real Name 2002-10-28 02:07:39 EST
We will eagering wait for your fix.
  Thanx for your prompt responses.
Comment 5 Need Real Name 2002-10-28 02:08:36 EST
Read "eagering" as "eagerly" !!
Comment 6 Alexander Larsson 2002-10-29 21:06:36 EST
I've spoken with the ypserv maintainer. Expect a patch that disables caching if
files == 0.
Comment 7 Alexander Larsson 2002-11-04 11:29:56 EST
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 12:00:45 EST
It is fixed in ypserv 2.6, availible at:

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 04:27:29 EST
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 00:36:28 EST
I will try this out.
Comment 11 Need Real Name 2002-11-12 02:01:57 EST
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 13 Need Real Name 2002-11-12 22:56:50 EST
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 03:39:20 EST
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 03:55:37 EST
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 04:30:27 EST
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 14:31:13 EST
It's getting pulled into trees, probably a transient push script error.
Comment 18 Alexander Larsson 2002-11-18 06:04:15 EST
Nah. It was once there. But got removed somehow.
Comment 19 Need Real Name 2002-11-20 05:23:54 EST
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 06:08:37 EST
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 07:26:09 EST
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 !!

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