Date: Sat, 6 Mar 1999 19:24:20 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: freebsd-bugs@freebsd.org Subject: Re: bin/6234 Message-ID: <199903070124.TAA22313@home.dragondata.com> In-Reply-To: <199903062351.SAA09969@skynet.ctr.columbia.edu> from Bill Paul at "Mar 6, 1999 6:51:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> >
> > Specificing 'ypserv -d' makes ypserv completely unresponsive, and never
> > outputs any debugging... What more info do you want? :)
>
> How about "a lot."
>
> I want to know _PRECISELY_ the steps you took to arrive at this
> conclusion. Now, people never seem to understand just what I mean
> when I ask this. I don't just want hear "Well, I type ypserv -d, and
> it doesn't work." There are other important things besides this
> which can affect the result. I'm not there watching you, so you have
> to be very clear and detailed and _complete_ in your description
> of the problem. I don't want to have to go ten rounds of e-mail
> that starts with "ypserv -d doesn't work" before I get to "oh,
> yes, I did unplug the ethernet cable from the machine just before
> I tried to run ypserv -d; you mean that matters?"
>
> For example, when you run ypserv -d, are you being careful to
> kill any existing ypserv already running on the system? Are you
> aware of the fact that ypserv only prints debug messages when
> a client tries to bind to it and starts interacting with it? If
> a client is bound to an instance of ypserv and you kill ypserv
> to start a new instance, the client takes time before it times
> out the binding to the old instance and starts broadcasting to
> establish a new binding. It's only when that happens that the
> new ypserv in debug mode will start to produce output. But you
> didn't say how long you waited for ypserv to produce any output,
> you didn't say how long you waited for clients to connect or if
> you even tried to force any clients to rebind by killing and re-
> syarting ypbind (or using ypset). All you said is "it doesn't
> work."
>
> What you could also do is investigate farther. It's very easy
> to compile ypserv with -g and then run gdb on it. If you think
> it's not really doing anything, gdb will prove or disprove your
> suspicions beyond any doubt.
>
> -Bill
>
Ok, well, I'm not using NIS anymore, but i set it up again as a test just to
try this.
Running with 'ypserv' alone works fine. the client is able to ypcat, etc...
su-2.02# ypcat -t test
ypcat: no such map test. reason: No such map in server's domain
Running with 'ypserv -d', the client complains that the server isn't
responding. ypcat on the client won't work, displaying something like this:
su-2.02# ypcat -t test
yp_next: clnt_call: RPC: Success
yp_next: clnt_call: RPC: Success
yp_next: clnt_call: RPC: Success
yp_next: clnt_call: RPC: Success
(10 second delays between each line)
It also shows up in rpcinfo, with or without -p....
100004 1 udp 669 ypserv
100004 2 udp 669 ypserv
100004 1 tcp 1010 ypserv
100004 2 tcp 1010 ypserv
root 20945 0.0 0.9 192 544 p4 S+ 7:00PM 0:00.02 ypserv -d
0 20945 20881 6 2 0 192 544 select S+ p4 0:00.02 ypserv -d
It shows it just stuck in 'select', and not doing anything. I get nothing
printed to the screen when I ypcat, nor any other NIS related activity.
A typical exchange when it is working (no -d) (shell1 is the client, home is the server)
19:19:34.739358 shell1.dragondata.com.982 > home.dragondata.com.1004: S 2096808723:2096808723(0) win 16384 <mss 1460> (DF)
19:19:34.739532 home.dragondata.com.1004 > shell1.dragondata.com.982: S 4010056489:4010056489(0) ack 2096808724 win 17520 <mss 1460> (DF)
19:19:34.739582 shell1.dragondata.com.982 > home.dragondata.com.1004: . ack 1 win 17520 (DF)
19:19:34.739716 shell1.dragondata.com.982 > home.dragondata.com.1004: P 1:73(72) ack 1 win 17520 (DF)
19:19:34.742107 home.dragondata.com.1004 > shell1.dragondata.com.982: P 1:45(44) ack 73 win 17520 (DF)
19:19:34.742219 shell1.dragondata.com.982 > home.dragondata.com.1004: F 73:73(0) ack 45 win 17520 (DF)
19:19:34.742345 home.dragondata.com.1004 > shell1.dragondata.com.982: . ack 74 win 17520 (DF)
19:19:34.742479 home.dragondata.com.1004 > shell1.dragondata.com.982: F 45:45(0) ack 74 win 17520 (DF)
19:19:34.742525 shell1.dragondata.com.982 > home.dragondata.com.1004: . ack 46 win 17520 (DF)
With -d:
19:20:15.571450 shell1.dragondata.com.981 > home.dragondata.com.1010: S 2110109802:2110109802(0) win 16384 <mss 1460> (DF)
19:20:15.571615 home.dragondata.com.1010 > shell1.dragondata.com.981: S 4021564131:4021564131(0) ack 2110109803 win 17520 <mss 1460> (DF)
19:20:15.571668 shell1.dragondata.com.981 > home.dragondata.com.1010: . ack 1 win 17520 (DF)
19:20:15.571795 shell1.dragondata.com.981 > home.dragondata.com.1010: P 1:73(72) ack 1 win 17520 (DF)
19:20:15.747224 home.dragondata.com.1010 > shell1.dragondata.com.981: . ack 73 win 17448 (DF)
19:20:25.577589 shell1.dragondata.com.981 > home.dragondata.com.1010: F 73:73(0) ack 1 win 17520 (DF)
19:20:25.577708 home.dragondata.com.1010 > shell1.dragondata.com.981: . ack 74 win 17448 (DF)
19:20:25.578605 shell1.dragondata.com.980 > home.dragondata.com.1010: S 2112266693:2112266693(0) win 16384 <mss 1460> (DF)
19:20:25.578790 home.dragondata.com.1010 > shell1.dragondata.com.980: S 4023644134:4023644134(0) ack 2112266694 win 17520 <mss 1460> (DF)
19:20:25.578837 shell1.dragondata.com.980 > home.dragondata.com.1010: . ack 1 win 17520 (DF)
19:20:25.578915 shell1.dragondata.com.980 > home.dragondata.com.1010: P 1:73(72) ack 1 win 17520 (DF)
19:20:25.747055 home.dragondata.com.1010 > shell1.dragondata.com.980: . ack 73 win 17448 (DF)
19:20:35.588103 shell1.dragondata.com.980 > home.dragondata.com.1010: F 73:73(0) ack 1 win 17520 (DF)
19:20:35.588216 home.dragondata.com.1010 > shell1.dragondata.com.980: . ack 74 win 17448 (DF)
19:20:35.589099 shell1.dragondata.com.979 > home.dragondata.com.1010: S 2114447289:2114447289(0) win 16384 <mss 1460> (DF)
19:20:35.589281 home.dragondata.com.1010 > shell1.dragondata.com.979: S 4026146660:4026146660(0) ack 2114447290 win 17520 <mss 1460> (DF)
19:20:35.589328 shell1.dragondata.com.979 > home.dragondata.com.1010: . ack 1 win 17520 (DF)
19:20:35.589408 shell1.dragondata.com.979 > home.dragondata.com.1010: P 1:73(72) ack 1 win 17520 (DF)
19:20:35.746875 home.dragondata.com.1010 > shell1.dragondata.com.979: . ack 73 win 17448 (DF)
I don't have time tonight to gdb or ktrace this, to see what it's doing, but
I can experiment more on my test network on Monday.
And to answer your questions.... Yes, I made sure to kill the old ypserv. I
waited 15 minutes this time to allow the client to bind to the new instance.
I'm aware that ypserv -d doesn't print anything until a client does
something. I tried killing/restarting ypbind, too.
Kevin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903070124.TAA22313>