From andre.albsmeier@mchp.siemens.de Sat Jul  3 06:03:29 1999
Return-Path: <andre.albsmeier@mchp.siemens.de>
Received: from david.siemens.de (david.siemens.de [192.35.17.14])
	by hub.freebsd.org (Postfix) with ESMTP id EC4E014DA8
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  3 Jul 1999 06:03:22 -0700 (PDT)
	(envelope-from andre.albsmeier@mchp.siemens.de)
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.14])
	by david.siemens.de (8.9.3/8.9.3) with ESMTP id PAA00205
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 3 Jul 1999 15:03:17 +0200 (MET DST)
Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7])
	by mail2.siemens.de (8.9.3/8.9.3) with ESMTP id PAA03615
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 3 Jul 1999 15:03:16 +0200 (MET DST)
Received: (from daemon@localhost)
	by curry.mchp.siemens.de (8.9.3/8.9.3) id PAA70936
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 3 Jul 1999 15:03:16 +0200 (CEST)
Message-Id: <199907031303.PAA04178@internal>
Date: Sat, 3 Jul 1999 15:03:14 +0200 (CEST)
From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: FreeBSD-gnats-submit@freebsd.org
Subject: yppush broken when pushing to 2 or more slaves
X-Send-Pr-Version: 3.2

>Number:         12496
>Category:       bin
>Synopsis:       yppush broken when pushing to 2 or more slaves
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul  3 06:10:01 PDT 1999
>Closed-Date:    Fri Dec 17 11:59:46 PST 1999
>Last-Modified:  Fri Dec 17 12:00:39 PST 1999
>Originator:     Andre Albsmeier
>Release:        FreeBSD 3.2-STABLE i386
>Organization:
>Environment:

One NIS master server running 3.2-STABLE and two or more NIS slaves 
running 3.2-STABLE as well.

>Description:

We have a NIS master called "server" and two NIS slaves called
"paul" and "printfix". On the NIS master we run yppush manually.
The normal output would be:

root@server:/var/yp>yppush -vvv mail.aliases
yppush: initiating transfer: mail.aliases -> printfix.ofw.tld (transid = 928055141)
yppush: printfix.ofw.tld has been called
yppush: checking return status: transaction ID: 928055141
yppush: transfer of map mail.aliases to server printfix.ofw.tld failed
yppush: status returned by ypxfr: Master's version not newer
yppush: initiating transfer: mail.aliases -> paul.ofw.tld (transid = 928055142)
yppush: paul.ofw.tld has been called
yppush: all jobs dispatched
yppush: paul.ofw.tld has not responded
yppush: printfix.ofw.tld has responded
yppush: 1 transfer still pending
yppush: checking return status: transaction ID: 928055142
yppush: transfer of map mail.aliases to server paul.ofw.tld failed
yppush: status returned by ypxfr: Master's version not newer
yppush: paul.ofw.tld has responded
yppush: printfix.ofw.tld has responded
yppush: all transfers complete


If we use a libexec/rtld-elf/rtld.c with version 1.13.2.8 or 1.13.2.9,
yppush fails in a way that it timeouts when waiting for the ack callback
from the second slave. Here is the ouput:

root@server:/var/yp>yppush -vvv mail.aliases
yppush: initiating transfer: mail.aliases -> printfix.ofw.tld (transid = 928055178)
yppush: printfix.ofw.tld has been called
yppush: checking return status: transaction ID: 928055178
yppush: transfer of map mail.aliases to server printfix.ofw.tld failed
yppush: status returned by ypxfr: Master's version not newer
yppush: initiating transfer: mail.aliases -> paul.ofw.tld (transid = 928055179)
yppush: paul.ofw.tld has been called
yppush: all jobs dispatched
yppush: paul.ofw.tld has not responded
yppush: printfix.ofw.tld has responded
yppush: 1 transfer still pending
/*****  here we wait about 5 Minutes  *****/
yppush: timed out
yppush: warning: exiting with transfer to paul.ofw.tld (transid = 928055179) still pending


One of the changes that were brought into libexec/rtld-elf/rtld.c with
version 1.13.2.8 is the following part of the code:

@@ -287,6 +285,10 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
     if (do_copy_relocations(obj_main) == -1)
        die();
 
+    dbg("initializing key program variables");
+    set_program_var("__progname", argv[0] != NULL ? basename(argv[0]) : "");
+    set_program_var("environ", env);
+
     dbg("calling _init functions");
     call_init_functions(obj_main->next);


If we remove one or both of the set_program_var lines it works again.
We can also add a third line so the code looks like:

+    set_program_var("__progname", argv[0] != NULL ? basename(argv[0]) : "");
+    set_program_var("environ", "dummy");
+    set_program_var("environ", env);


This also will work. I had an excessive private email exchange with
John Polstra about this and he finally came to the point that there must
be something wrong with yppush which hits depending of what is left in
the memory by rtld.c.

In the meantime we are at a libexec/rtld-elf/rtld.c with version 1.13.2.11.
Here the things are reversed: It works with the original rtld.c and
breaks with the set_program_var("environ", "dummy"); line added.


>How-To-Repeat:

See above. Try with a libexec/rtld-elf/rtld.c with version 1.13.2.8.

>Fix:
	
Currently unknown. If anyone wants to dig into it I can supply the 
mails exchanged between John Polstra and me (yes, he agreed to it).
I will also happily run any tests or try out suggestions.

>Release-Note:
>Audit-Trail:

From: Bob Willcox <bob@luke.pmr.com>
To: freebsd-gnats-submit@freebsd.org, andre.albsmeier@mchp.siemens.de
Cc:  
Subject: Re: bin/12496: yppush broken when pushing to 2 or more slaves
Date: Tue, 20 Jul 1999 09:14:21 -0500

 I to, am seeing this problem (though I have only one slave).  The system
 I am running yppush on (the master) is:
 
 FreeBSD obiwan.pmr.com 3.2-STABLE FreeBSD 3.2-STABLE #10: Sun Jun 27 14:00:22 CDT 1999     bob@obiwan.pmr.com:/usr2/src/sys/compile/OBIWAN  i386
 
 Ifdef'ing out the two lines set_program_var lines mentioned by Andre
 works around (or hides) the problem for me.
 
 Bob
 
 -- 
 Bob Willcox                 Don't tell me that worry doesn't do any good.
 bob@pmr.com                 I know better. The things I worry about don't
 Austin, TX                  happen.          -- Watchman Examiner
 

From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: Bob Willcox <bob@pmr.com>
Cc: freebsd-gnats-submit@freebsd.org, andre.albsmeier@mchp.siemens.de
Subject: Re: bin/12496: yppush broken when pushing to 2 or more slaves
Date: Tue, 20 Jul 1999 16:18:08 +0200

 On Tue, 20-Jul-1999 at 09:14:21 -0500, Bob Willcox wrote:
 > I to, am seeing this problem (though I have only one slave).  The system
 > I am running yppush on (the master) is:
 
 Well, you have one real slave but the master appears in your ypservers
 line as well, IIRC. So yppush upgrades a) the real slave and b) the master
 and this makes again two hosts to be contacted by yppush.
 
 > 
 > FreeBSD obiwan.pmr.com 3.2-STABLE FreeBSD 3.2-STABLE #10: Sun Jun 27 14:00:22 CDT 1999     bob@obiwan.pmr.com:/usr2/src/sys/compile/OBIWAN  i386
 > 
 > Ifdef'ing out the two lines set_program_var lines mentioned by Andre
 > works around (or hides) the problem for me.
 > 
 > Bob
 > 
 > -- 
 > Bob Willcox                 Don't tell me that worry doesn't do any good.
 > bob@pmr.com                 I know better. The things I worry about don't
 > Austin, TX                  happen.          -- Watchman Examiner
 
 	-Andre
 

From: Bob Willcox <bob@luke.pmr.com>
To: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc: Bob Willcox <bob@pmr.com>, freebsd-gnats-submit@freebsd.org
Subject: Re: bin/12496: yppush broken when pushing to 2 or more slaves
Date: Tue, 20 Jul 1999 10:31:46 -0500

 On Tue, Jul 20, 1999 at 04:18:08PM +0200, Andre Albsmeier wrote:
 > On Tue, 20-Jul-1999 at 09:14:21 -0500, Bob Willcox wrote:
 > > I to, am seeing this problem (though I have only one slave).  The system
 > > I am running yppush on (the master) is:
 > 
 > Well, you have one real slave but the master appears in your ypservers
 > line as well, IIRC. So yppush upgrades a) the real slave and b) the master
 > and this makes again two hosts to be contacted by yppush.
 
 Hmm, true.  I had forgotten about that.  Seems this is the second time
 you have pointed it out to me.  :-(
 
 Bob
 
 > 
 > > 
 > > FreeBSD obiwan.pmr.com 3.2-STABLE FreeBSD 3.2-STABLE #10: Sun Jun 27 14:00:22 CDT 1999     bob@obiwan.pmr.com:/usr2/src/sys/compile/OBIWAN  i386
 > > 
 > > Ifdef'ing out the two lines set_program_var lines mentioned by Andre
 > > works around (or hides) the problem for me.
 > > 
 > > Bob
 > > 
 > > -- 
 > > Bob Willcox                 Don't tell me that worry doesn't do any good.
 > > bob@pmr.com                 I know better. The things I worry about don't
 > > Austin, TX                  happen.          -- Watchman Examiner
 > 
 > 	-Andre
 
 -- 
 Bob Willcox                 Don't tell me that worry doesn't do any good.
 bob@pmr.com                 I know better. The things I worry about don't
 Austin, TX                  happen.          -- Watchman Examiner
 
Responsible-Changed-From-To: freebsd-bugs->n_hibma 
Responsible-Changed-By: n_hibma 
Responsible-Changed-When: Wed Jul 21 00:47:16 PDT 1999 
Responsible-Changed-Why:  
If it is true that the server is pushed another copy and this is 
the problem described above, we might just need to add another if 
statement somewhere. I'll have a look to see whether this is a possible 
solution to the problem. 
Responsible-Changed-From-To: n_hibma->freebsd-bugs 
Responsible-Changed-By: n_hibma 
Responsible-Changed-When: Wed Jul 21 13:46:21 PDT 1999 
Responsible-Changed-Why:  
Maybe I should try and understand the PR before saying I will take it :-} 

From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/12496: yppush broken when pushing to 2 or more slaves
Date: Thu, 16 Dec 1999 21:22:11 +0100

 I think, this PR can be closed. I have nevermore seen the problem
 for a long time. I had some private email exchange with John Polstra
 about it a while ago and we never found a reason for the errorneous
 behaviour but maybe it has been fixed without knowing it.
 
 If the problem appears again, we probably can open it again.
 
 	-Andre
 
State-Changed-From-To: open->closed 
State-Changed-By: steve 
State-Changed-When: Fri Dec 17 11:59:46 PST 1999 
State-Changed-Why:  

Originator stated that he is no longer seeing the problem mentioned 
in this PR. 
>Unformatted:
