Date: Tue, 7 May 1996 12:32:28 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: jdli@freebsd.csie.nctu.edu.tw (Jian-Da Li) Cc: freebsd-current@FreeBSD.ORG Subject: Re: NIS problem on 0501-SNAP Message-ID: <199605071632.MAA03960@skynet.ctr.columbia.edu> In-Reply-To: <199605050459.MAA26395@FreeBSD.csie.NCTU.edu.tw> from "Jian-Da Li" at May 5, 96 12:59:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the world, Jian-Da Li had to walk into mine and say: > Hi : > > NIS isn't too stable in my 2.2-960501-SNAP (in fact, nis isn't stable > since I install 2.2 2 monthes ago). > This is a self-nis machine, it's a nis server and it binds itself. > When boot up more than 2 days, nis will begin to act strange. > It will keep on dumping messages on the screen .. > "YP: server for domain FREEBSD not responding, retrying" > "yp_match: clnt_call: RPC: Timed out" > (I used to run screen-3.7.1, when one of the window dumps errors, > other windows work fine just slower in name-resolve. I will have > to kill the window and create a new one to solve it) > > At that time there will be lots of "ypserv -n" running (at least 10), > new "ypserv -n" keeps on forking, old ypserv will die, it will > keep the number of ypserv fixed. > Of course, the original "ypserv -n" (the 1st one) will not die. Okay, ypserv -n turns on DNS lookups (which means that when searching the hosts map, ypserv will try to use DNS to resolve names that it doesn't know about). If the only client connected to you is yourself, you should probably turn this off and use real DNS lookups. Make sure /etc/resolv.conf is set up correctly and edit /etc/host.conf so that you don't use NIS for hostname lookups. ypserv only fork()s for two reasons: one is to do DNS lookups, the other is to handle yp_all() requests (such as you'd get by doing a ypcat or ypxfr). Both of these can take a lot of time, so they're handled in sub-processes to prevent the parent ypserv from blocking. There is a maximum number of processes that it will fork() before it will stop and wait for some of them to die. > Sometimes yppasswdd will return error code when changing password This is too vague. What error? Look in /var/log/messages for errors from rpc.yppasswdd. When rpc.yppasswdd fails, it tells you why in the system log. > (reboot solves it) This isn't Windoze, okay? You have to be more creative than that. Does restarting rpc.yppasswd fix it? Are you sure you're running both the rpc.yppasswdd and passwd/chpass commands from the same release? Does it happen only when changing passwords from the FreeBSD client, or does it happen from other clients? > The longer the machine up, the worse it will be. (longer delay in > nis name resolving) You need to provide more information. How big are your NIS maps? Does ypserv seem to be using progressively more memory? (Do a 'ps -auxwww | grep yp' and check the VSZ and RSS of the parent ypserv.) Are you in fact using ypserv to do DNS lookups? Does this server have any other clients bound to it besides itself? If so, how many? Are they also FreeBSD machines? > BTW, I saw new yp_mkdb commited, but it isn't in > $SRC/usr.sbin/Makefile (and will not be built) Guh... fixed. > Help ?! Thanks. You gotta help me first. Describe your configuration oin more detail so I know what I'm up against. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605071632.MAA03960>