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>