It's slow, but it seems to work reliably.
One possibility: we use a patched amd binary. sources and/or binary
available upon request. The patches originally came from Richard
Kaszeta.
For what it's worth, we used to have some VERY mysterious amd problems
on SunOS 4.1.x. It's a weird program.
BTW, I use amd on linux in conjunction with a small python script that
converts a hierarchy of sun automounter maps (out of the NIS) to amd
maps. This allows amd on linux to behave very much like a commercial
unix equipped with a sun-derived automounter. Just slower.
Nelson Minar wrote:
>
> davis@space.mit.edu (John E. Davis) writes:
> > On 27 Jan 1997 20:09:05 -0500, Nelson Minar <nelson@media.mit.edu> wrote:
> > >For the past few months my Linux box has had persistent, occasional
> > >problems of processes hanging in rpc_recv.
> > I am also having this problem with 2.0.28 and amd (amd920824upl90).
> > In addition to hanging in rpc_revc, I also have process that hang in
> > wait_on_page.
>
> I see this as well, but wasn't sure it was NFS related. Is that call
> used when mapping in a non-cached part of the text image of a program?
> I see this bug most often in netscape. The netscape binary is not NFS
> mounted, but god knows what other files it uses.
>
> > I do not recall having any of these problems in the early 1.3.X series
> > and I certainly did not have them with 1.2.13. Something is definitely
> > wrong with the 2.0.XX NFS implementation.
>
> That's my impression too. Can anyone at least confirm these problems?
> No suggestions on what to fix?
>
> (I saw Adam Neat's suggestion to check the configuration of the
> loopback device, as well as hosts.allow/deny. I think those are
> correct for me. In any event, problems in those configurations would
> presumably cause catastrophic failure, not the occasional outage we're
> seeing.)