Date: Fri, 8 Nov 1996 06:37:38 -0800 (PST) From: Bill Paul <wpaul> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: dfr@render.com, dfr@freebsd.org, stable@freebsd.org Subject: Re: Weirdie in mountd perhaps you can help me with... Message-ID: <199611081437.GAA06505@freefall.freebsd.org> In-Reply-To: <4597.847460716@time.cdrom.com> from "Jordan K. Hubbard" at Nov 8, 96 05:45:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Mountd wakes up when any filesystem (local or remote) is mounted so that > > it can correctly export local filesystems depending on the contents of > > /etc/exports. > > Ah, OK, that makes sense.. You can also test it somewhat using the rpcinfo command by asking it to ping mountd's NULLPROC (RPC procudure 0 is usually reserved for a null function that basically acts as a loopback of sorts; rpcinfo can be used to call the null procedure and if you get an answer, you know the RPC server is still alive). If the process is blocked inside a select loop in the DNS code though, I'm not sure you would get an immediate answer. > > My guess is that it is trying to DNS resolve a badly formed address. The > > timeouts for this are pretty long. Impossible to tell without knowing the > > arguments to gethostbyaddr and res_query :-(. This is my guess too. If all the hosts you export too are local and the primary nameserver for them is close by, you shouldn't see much trouble like this unless perhaps you try mounting a filesystem at the same time that someone is reloading the nameserver or something. One way you might get around this is to put the names of all your permitted NFS clients (and other important hosts) in /etc/hosts and fixing /etc/host.conf so that it searches /etc/hosts first and then DNS. One case where this workaround will not work is if someone at a remote location tries to NFS mount your filesystems without permission (perhaps for nefarious purposes like breaking in or stealing your memoirs.) If they are really far away, or on a crummy network (like Sprint :), or they're using an unregistered IP, or the nameservers for their domain are hosed, mountd could get stuck for a while trying to resolve (or reverse resolve) them. If you suspect this may be the case, you can easily add code to the procedure in mountd where mount requests are processed to syslog(3) the IP addresses of requesting hosts. Now that I think of it, this may be a good idea in general. I don't remember if mountd flags unauthorized mount attempts. > Understood. It might also have been a transient error of other > origins. I've still got the patient under guard and will report any > further suspicious behavior. :-) Take two SIMM modules and call us in the morning. > I'll also try to figure out why I'm not getting argument values in > my stack traces. Well, the DNS code is inside libc, so unless you compile libc with -g or extract the libc/net code, compile that with -g and link against it explicitly, gdb won't be able to show your more than function names. (You can also poke around in registers but this is a drag.) Come to think of it, the RPC code would have to be compiled with -g too. -Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611081437.GAA06505>