From nobody@FreeBSD.ORG Tue Jun 22 12:54:07 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 146E81552E; Tue, 22 Jun 1999 12:54:07 -0700 (PDT)
Message-Id: <19990622195407.146E81552E@hub.freebsd.org>
Date: Tue, 22 Jun 1999 12:54:07 -0700 (PDT)
From: mkc@graphics.cornell.edu
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal
X-Send-Pr-Version: www-1.0

>Number:         12349
>Category:       bin
>Synopsis:       3.2-R inetd doesn't re-read ALL configuration info at HUP signal
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    des
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 22 13:00:01 PDT 1999
>Closed-Date:    Sun Jan 13 08:06:04 PST 2002
>Last-Modified:  Sun Jan 13 08:06:04 PST 2002
>Originator:     Mitch Collinsworth
>Release:        3.2-R
>Organization:
Cornell University
>Environment:
FreeBSD benge.graphics.cornell.edu 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Tue May 18 04:05:08 GMT 1999     jkh@cathair:/usr/src/sys/compile/GENERIC  i386

>Description:
>How-To-Repeat:
1. vipw and append "+:::::::::"
2. edit /etc/group and append "+:"
3. start ypbind
4. edit /etc/inetd.conf and append:
amanda dgram udp wait backup /usr/local/amanda/libexec/amandad amandad
5. send HUP signal to inetd

result: "No such user backup, service ignored".
>Fix:
A workaround is to kill inetd completely and restart it.
Not ideal when doing the above in a script on a live system that
may be performing other tasks at the time.

>Release-Note:
>Audit-Trail:

From: Dag-Erling Smorgrav <des@flood.ping.uio.no>
To: mkc@graphics.cornell.edu
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal
Date: 09 Jul 1999 13:11:23 +0200

 mkc@graphics.cornell.edu writes:
 > >How-To-Repeat:
 > 1. vipw and append "+:::::::::"
 > 2. edit /etc/group and append "+:"
 > 3. start ypbind
 > 4. edit /etc/inetd.conf and append:
 > amanda dgram udp wait backup /usr/local/amanda/libexec/amandad amandad
 > 5. send HUP signal to inetd
 > 
 > result: "No such user backup, service ignored".
 
 This is caused by the fact that the C library caches metainformation
 about the password files (e.g. whether or not to use NIS, whether or
 not it has access to the master password map, etc.) and there is
 currently no way of forcing it to clear its cache.
 
 This is really a libc bug, not an inetd bug. It is closely related to
 bin/10281.
 
 DES
 -- 
 Dag-Erling Smorgrav - des@flood.ping.uio.no
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal
Date: Fri, 09 Jul 1999 14:04:06 +0200

 Hi DES,
 
 You say that this has to do with bin/10281, but that PR seems totally
 unrelated. Which PR did you mean to cross-reference?
 
 Ciao,
 Sheldon.
 
Responsible-Changed-From-To: freebsd-bugs->des 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Fri Jul 9 06:34:13 PDT 1999 
Responsible-Changed-Why:  
DES has a handle on the problem. 

From: Dag-Erling Smorgrav <des@flood.ping.uio.no>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal
Date: 09 Jul 1999 15:54:23 +0200

 Sheldon Hearn <sheldonh@uunet.co.za> writes:
 > On 09 Jul 1999 15:30:06 +0200, Dag-Erling Smorgrav wrote:
 > > I committed a stopgap fix to -CURRENT in March (rev 1.49 of
 > > getpwent.c), but (oops!) forgot to commit it.
 > Do you mean that you forgot to MFC it? As I understand the situation,
 > then, this is not a problem in CURRENT, but only in RELENG_3.
 
 Uh, yes, I should have added " to -STABLE" before the period. I just
 MFCed it.
 
 BTW, my patch does not address the problem described in this PR. I
 still don't invalidate the cache, I just try to recover gracefully
 when the system thwaps me over the head and yells "Yo! Wake up! Your
 cache is stale!". What needs to be done:
 
  * be better at detecting PID and UID changes (i.e. forking and
    dropping privs), since they cause problems with NIS.
 
  * be better at detecting the addition / deletion of NIS lines in
    /etc/{passwd,group}.
 
 The latter would fix bin/12349, but is quite tricky.
 
 There's also the problem of "optimizing for the rare case"; properly
 fixing these problems may add some overhead to the getpw*() functions,
 which would penalize heavy consumers (web / ftp servers, mail delivery
 agents etc).
 
 DES
 -- 
 Dag-Erling Smorgrav - des@flood.ping.uio.no
 

From: Dag-Erling Smorgrav <des@flood.ping.uio.no>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal
Date: 09 Jul 1999 15:30:06 +0200

 Sheldon Hearn <sheldonh@uunet.co.za> writes:
 > You say that this has to do with bin/10281, but that PR seems totally
 > unrelated. Which PR did you mean to cross-reference?
 
 Sorry, I meant bin/10821: "getpwent() fails on NIS clients after
 dropping privs", which describes a differnt set of symptoms of the
 same bug / design flaw. I submitted it and intend to fix it myself,
 but haven't had time yet. I committed a stopgap fix to -CURRENT in
 March (rev 1.49 of getpwent.c), but (oops!) forgot to commit it.
 
 DES
 -- 
 Dag-Erling Smorgrav - des@flood.ping.uio.no
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal 
Date: Fri, 09 Jul 1999 15:34:02 +0200

 On 09 Jul 1999 15:30:06 +0200, Dag-Erling Smorgrav wrote:
 
 > Sorry, I meant bin/10821: "getpwent() fails on NIS clients after
 > dropping privs", which describes a differnt set of symptoms of the
 > same bug / design flaw. I submitted it and intend to fix it myself,
 > but haven't had time yet.
 
 Cool, so long as someone has a handle on it. NIS isn't something I've
 played with.
 
 > I committed a stopgap fix to -CURRENT in March (rev 1.49 of
 > getpwent.c), but (oops!) forgot to commit it.
 
 Do you mean that you forgot to MFC it? As I understand the situation,
 then, this is not a problem in CURRENT, but only in RELENG_3.
 
 Ciao,
 Sheldon.
 

From: Mitch Collinsworth <mkc@Graphics.Cornell.EDU>
To: Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc: freebsd-gnats-submit@FreeBSD.ORG, Doug <Doug@gorean.org>,
	mkc@broccoli.graphics.cornell.edu
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at 
 HUP signal
Date: Wed, 21 Jul 1999 10:45:26 -0400

 >mkc@graphics.cornell.edu writes:
 >> >How-To-Repeat:
 >> 1. vipw and append "+:::::::::"
 >> 2. edit /etc/group and append "+:"
 >> 3. start ypbind
 >> 4. edit /etc/inetd.conf and append:
 >> amanda dgram udp wait backup /usr/local/amanda/libexec/amandad amandad
 >> 5. send HUP signal to inetd
 >> 
 >> result: "No such user backup, service ignored".
 >
 >This is caused by the fact that the C library caches metainformation
 >about the password files (e.g. whether or not to use NIS, whether or
 >not it has access to the master password map, etc.) and there is
 >currently no way of forcing it to clear its cache.
 >
 >This is really a libc bug, not an inetd bug. It is closely related to
 >bin/10281.
 >
 >DES
 >-- 
 >Dag-Erling Smorgrav - des@flood.ping.uio.no
 
 
 Funny, I got a different response from <Doug@gorean.org> after posting
 to freebsd-questions.  Doug says it's already been fixed in 3.2-Stable:
 
 
 >Date: Mon, 28 Jun 1999 14:58:15 -0700 (PDT)
 >From: Doug <Doug@gorean.org>
 >X-sender: doug@dt054n86.san.rr.com
 >To: Mitch Collinsworth <mkc@Graphics.Cornell.EDU>
 >Cc: Doug White <dwhite@resnet.uoregon.edu>, freebsd-questions@FreeBSD.ORG,
 >        markm@FreeBSD.ORG
 >Subject: Re: 3.2-R: problem with inetd and NIS
 >In-reply-to: <199906221954.AA279571283@broccoli.graphics.cornell.edu>
 >Message-id: <Pine.BSF.4.05.9906281457480.7668-100000@dt054n86.san.rr.com>
 >Mime-version: 1.0
 >Content-type: TEXT/PLAIN; charset=US-ASCII
 >
 >On Tue, 22 Jun 1999, Mitch Collinsworth wrote:
 >
 >> >Did you shutdown inetd totally then restart it?  Apparently kill -HUP
 >> >inetd doesn't quite work correctly for certain configuration files.  
 >> 
 >> No I didn't.  I've never heard of such a thing.  However...  It does
 >> in fact work!  Now that we know this, it is conceivable 3.0-R and 3.1-R
 >> may have the same problem since I can't say for sure that I didn't
 >> reboot those systems sometime between configuration and testing.
 >> 
 >> I would have to classify this as a bug.   The HUP signal should cause
 >> all configuration info to be re-loaded.
 >
 >	It is a bug, and it's fixed in -stable.
 >
 >HTH,
 >
 >Doug
 >-- 
 >On account of being a democracy and run by the people, we are the only
 >nation in the world that has to keep a government four years, no matter
 >what it does.
 >                -- Will Rogers
 
 
 -Mitch
 
 

From: Dag-Erling Smorgrav <des@flood.ping.uio.no>
To: Mitch Collinsworth <mkc@Graphics.Cornell.EDU>
Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>,
	freebsd-gnats-submit@FreeBSD.ORG, Doug <Doug@gorean.org>,
	mkc@broccoli.graphics.cornell.edu
Subject: Re: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at   HUP signal
Date: 21 Jul 1999 17:04:10 +0200

 Mitch Collinsworth <mkc@Graphics.Cornell.EDU> writes:
 > Funny, I got a different response from <Doug@gorean.org> after posting
 > to freebsd-questions.  Doug says it's already been fixed in 3.2-Stable:
 
 Well, you're free to believe whomever you want.
 
 DES
 -- 
 Dag-Erling Smorgrav - des@flood.ping.uio.no
 
State-Changed-From-To: open->closed 
State-Changed-By: des 
State-Changed-When: Sun Jan 13 08:06:04 PST 2002 
State-Changed-Why:  
This particular bug probably qualifies as a feature. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=12349 
>Unformatted:
 >> >> I am putting an entry in inetd.conf with a non-root user field.
 >> >> This user is defined in NIS rather than in /etc/master.passwd.
 >> >> On 3.0-R and 3.1-R this works.  On 3.2-R when I HUP inetd I get:
 >> >> "No such user 'user', service ignored".  Putting a non-NIS entry
 >> >> into master.passwd for this user does get inetd to start the
 >> >> service.
 >> >
 >> >This begs the question, is NIS working?  How did you activate NIS?
 >> 
 >> Yes, NIS is working for everything except inetd in 3.2-R.
 >
 >Did you shutdown inetd totally then restart it?  Apparently kill -HUP
 >inetd doesn't quite work correctly for certain configuration files.  
 
 No I didn't.  I've never heard of such a thing.  However...  It does
 in fact work!  Now that we know this, it is conceivable 3.0-R and 3.1-R
 may have the same problem since I can't say for sure that I didn't
 reboot those systems sometime between configuration and testing.
 
 I would have to classify this as a bug.   The HUP signal should cause
 all configuration info to be re-loaded.
 
 -Mitch
