Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!mcvax!ukc!strath-cs!maxwell!jim
From: jim@maxwell.cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.unix.ultrix
Subject: Re: nfs daemon blocks system.
Message-ID: <94@baird.cs.strath.ac.uk>
Date: 25 Apr 89 09:26:49 GMT
References: <278@kubix.UUCP> <1659@eric.mpr.ca> <11582@s.ms.uky.edu> <6677@cbmvax.UUCP>
Sender: news@cs.strath.ac.uk
Reply-To: jim@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 28

In article <6677@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
>Well, I was about to suggest that you blast the offending daemon with
>at quit signal and see if you could get a useful "core" file, which
>would at least give some clue as to what the daemon thought is was up
>to.  Unfortunatly, the object is stripped, which makes debugging all
>but impossible. 

This would not be much help, even if the daemons were unstripped. Both
nfsd and biod are trivial programs - they execute only kernel code apart
from a small amount of initialisation at start up. All nfsd and biod do
is detach from their control tty and then invoke a system call that
NEVER returns. This puts the process into kernel mode, where it runs the
kernel's NFS client or server code.

Getting a core dump is not much use unless you know how to get hold of
the kernel stack inside the dump's u. area and then map that with the
kernel's symbol table [with the kernel sources by your side for
reference.... :-)]. You could get the daemon's stack backtrace much
easier using adb on /vmunix and /dev/kmem. Even then, that might be of
little use if the daemon is making repeated function calls and so all
you get is a snapshot of the daemon's kernel activity.

		Jim
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"!rof si ver tahw s'taht oS"