From owner-freebsd-bugs@FreeBSD.ORG Tue Nov 2 16:00:50 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F7DE16A4CF for ; Tue, 2 Nov 2004 16:00:50 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1154143D2D for ; Tue, 2 Nov 2004 16:00:50 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id iA2G0n3P025047 for ; Tue, 2 Nov 2004 16:00:49 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iA2G0nlx025044; Tue, 2 Nov 2004 16:00:49 GMT (envelope-from gnats) Resent-Date: Tue, 2 Nov 2004 16:00:49 GMT Resent-Message-Id: <200411021600.iA2G0nlx025044@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Trond Endrestøl Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33BAA16A4CE for ; Tue, 2 Nov 2004 15:53:04 +0000 (GMT) Received: from ramstind.gtf.ol.no (ramstind.gtf.ol.no [128.39.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2837C43D2D for ; Tue, 2 Nov 2004 15:53:03 +0000 (GMT) (envelope-from trond@ramstind.gtf.ol.no) Received: from ramstind.gtf.ol.no (Ximalas@localhost [127.0.0.1]) by ramstind.gtf.ol.no (8.12.9/8.12.11) with ESMTP id iA2Fqx29051776 for ; Tue, 2 Nov 2004 16:53:01 +0100 (CET) (envelope-from trond@ramstind.gtf.ol.no) Received: (from trond@localhost) by ramstind.gtf.ol.no (8.12.9/8.12.3/Submit) id iA2FqwJN051775; Tue, 2 Nov 2004 16:52:58 +0100 (CET) Message-Id: <200411021552.iA2FqwJN051775@ramstind.gtf.ol.no> Date: Tue, 2 Nov 2004 16:52:58 +0100 (CET) From: Trond Endrestøl To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: bin/73422: portmap forks ad infinitum when the NIS domain name is set, probably a bug in the RPC library X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Trond Endrestøl List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 16:00:50 -0000 >Number: 73422 >Category: bin >Synopsis: portmap forks ad infinitum when the NIS domain name is set, probably a bug in the RPC library >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 02 16:00:49 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Trond Endrestøl >Release: FreeBSD 4.10-RELEASE i386 >Organization: Private >Environment: >Description: I'm in the process of setting up NIS in my home and I've found a problem that I believe resides in the RPC library. I'm running 4.10-RELEASE and I've followed the instructions in the Handbook. I've used FreeBSD since 1998, but I have only recently turned my interest to NIS. (Speaking of the Handbook, has anyone tried these instructions lately and verified that you'll actually achieve the goal? Is NIS tested when a new -RELEASE is rolled out?) When portmap receives a request, any request, portmap uses the RPC library to maintain the port mappings. When the RPC library discovers the NIS domain name is set, it tries to get the port of the NIS client (i.e. ypbind). As a result, if ypbind is not registered, ypbind might even be in the process of registering with portmap right now, another portmap process is created to service the request. The new portmap process is still using the very same RPC library, which in turn discovers again the name of the NIS domain and tries to get hold of the port belonging to the NIS client, and next, the snowball is rolling and rolling, and soon the system has hundreds, if not thousands, of portmap processes getting nowhere. I've changed ypbind slightly so that it does not check the NIS domain name before checking the command line, see the patch below. Note: This is a very poor workaround! The real problem is still in the RPC library. My computers are all set up to be NIS servers, master or slaves, and are therefore commanded to bind to themselves. When the NIS servers and clients (i.e. ypserv and ypbind) are finally up and running, I can set the NIS domain name using domainname, and everything is OK unless ypbind dies. Should ypbind die, I need to unset the NIS domain name in order not to trigger this nasty problem in the RPC library, restart ypbind, and set the NIS domain name again. Can someone fix the RPC library? I guess the RPC library shouldn't create and post requests on its own when processing other requests. If no one corrects the RPC library, then part of the Handbook should be rewritten, at least make a note that the RPC system, and thus NIS, is broken. RPC and NFS is still working though. >How-To-Repeat: Run portmap with a NIS domain name set, and try engaging portmap by the use of rpcinfo, mountd, nfsd, whatever. >Fix: Patch for ypbind.c follows: *** ypbind.c.orig Fri Feb 15 01:46:59 2002 --- ypbind.c Tue Nov 2 13:47:58 2004 *************** *** 403,413 **** if (flock(yplockfd, LOCK_EX|LOCK_NB) == -1 && errno == EWOULDBLOCK) errx(1, "another ypbind is already running. Aborting"); - /* XXX domainname will be overriden if we use restricted mode */ - yp_get_default_domain(&domain_name); - if (domain_name[0] == '\0') - errx(1, "domainname not set. Aborting"); - for (i = 1; iRelease-Note: >Audit-Trail: >Unformatted: >System: