On Sun, 2008-01-06 at 13:34 -0500, Jim Duda wrote:
> Ian,
>
> All of my NFS based root file system computers operate without mice or
> keyboards. I read a few posts which claim that /dev/random might not
> provide any data on these type of machines.
>
> In my rc.local, I have simply removed /dev/random and created a link
> from random to /dev/urandom.
>
> Now everything works just fine!!
>
> Thanks for all your patience on this thread.
Wow, that's a surprise and yet so obvious in hindsight.
I'll have to work out a way to deal with that.
>
> Jim
>
> Jim Duda wrote:
> > Ian,
> >
> > I cannot explain why, but I wasn't able to get any debug message via
> > SYSLOG, however, I found that by using msg(""), I was able to add my own
> > debugging.
> >
> > I finally figured out the root cause of the hang. The program was
> > blocked down inside replicate.d, at the read of /dev/random.
> >
> > I have both /dev/random and /dev/urandom.
> >
> > By simply replacing /dev/random with /dev/urandom in replicate.c, my
> > hang problem was resolved and automount works just great.
> >
> > Does that make any sense?
> >
> > Jim
> >
> > Ian Kent wrote:
> >> On Fri, 2008-01-04 at 21:46 -0500, Jim Duda wrote:
> >>> Ian,
> >>>
> >>> On the machine that don't work properly, I get this from showmount.
> >>>
> >>> asterisk> showmount
> >>> Broken pipe
> >> That doesn't look very good.
> >> It may be an indication that RPC is somehow not right on the machine.
> >> I would expect output like (assuming the machine isn't actually being
> >> used as an NFS server):
> >> showmount: RPC: Program not registered
> >>
> >> Maybe the problem is as simple as portmap or rpcbind not running on the
> >> machine. But then I'd expect showmount to just return nothing.
> >>
> >>> Does that mean anything to you?
> >>>
> >>> Note that in my auto.master file, I have /net commented out ...
> >>>
> >>> Jim
> >>>
> >>> Ian Kent wrote:
> >>>> On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
> >>>>> Ian,
> >>>>>
> >>>>> Here in spawn.c
> >>>>>
> >>>>> errp = 0;
> >>>>> do {
> >>>>> while ((errn =
> >>>>> read(pipefd[0], errbuf + errp,
> >>>>> ERRBUFSIZ - errp)) == -1
> >>>>> && errno == EINTR);
> >>>> I'm not sure this really says much except that autofs is waiting for
> >>>> mount(8) (or umount(8) as the case may be) to complete.
> >>>>
> >>>> Usually you will see a mount process running if mount isn't completing,
> >>>> in which case, it becomes a matter of working out why mount can't
> >>>> complete the mount. If we were logging debug info then usually we would
> >>>> be able to get the mount command used which is often helpful. OTOH, if
> >>>> there isn't any process (either mount or another automount process) then
> >>>> perhaps mount has seg faulted and autofs is waiting for a reply but,
> >>>> usually, if that happens the daemon gets a signal and continues with
> >>>> what looks like a successful mount which it often really isn't.
> >>>>
> >>>>> Jim Duda wrote:
> >>>>>> Ian,
> >>>>>>
> >>>>>> I do have daemon.*, I got it backwards in the last post.
> >>>>>>
> >>>>>> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
> >>>>>>
> >>>>>> Jim
> >>>>>>
> >>>>>> Ian Kent wrote:
> >>>>>>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
> >>>>>>>> Ian,
> >>>>>>>>
> >>>>>>>> Adding *.daemon simply resulted in the same information being dumped
> >>>>>>>> to
> >>>>>>>> the syslog file, however, twice. So, no new information.
> >>>>>>> That should be daemon.* and usually you would log it to a different
> >>>>>>> file
> >>>>>>> when adding a syslog entry like that but I don't think that will make
> >>>>>>> any difference.
> >>>>>>>
> >>>>>>> I can't remember how logging to a syslog server works now but does the
> >>>>>>> syslog configuration on the server also limit what is logged?
> >>>>>>>
> >>>>>>>> Once automount gets wedged, I cannot use gdb to interrogate the
> >>>>>>>> threads,
> >>>>>>>> I cannot break into the program after it's wedged.
> >>>> I haven't seen that behavior before and I've debugged some really broken
> >>>> code in the early version 5 development. Perhaps this is something other
> >>>> than just autofs?
> >>>>
> >>>>>>>> I'm by no means a power gdb user.
> >>>>>>> Me nether.
> >>>>>>>
> >>>>>>>> I did:
> >>>>>>>>
> >>>>>>>> set detach-on-fork off, simply based on a recommended help from ddd.
> >>>>>>>>
> >>>>>>>> I traced the program all the way down into mount_bind.c, in the
> >>>>>>>> mount_init function, then into spawn.c, where it did the first fork.
> >>>>>>>> The program was wedged in spawn.c on line 186 at the first do while
> >>>>>>>> loop
> >>>>>>>> after the fork.
> >>>>>>>>
> >>>>>>>> The program though do_read_master, mod->lookup_int, then into
> >>>>>>>> open_mount
> >>>>>>>> for "nfs" before it got to the first spawn.
> >>>>>>>>
> >>>>>>>> I don't know how helpful any of this information is for you in
> >>>>>>>> helping
> >>>>>>>> me determine what is different about my funky root file system which
> >>>>>>>> causes a lockup, but thanks for trying.
> >>>>>>> I'm not sure either but one thing is sure, problems are almost always
> >>>>>>> different from what you think they are when you finally get hard
> >>>>>>> evidence.
> >>>>>>>
> >>>>>>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
> >>>>>>>
> >>>>>>> How about we try getting rid of a recent patch to this area of the
> >>>>>>> code
> >>>>>>> and rebuild autofs and see if that helps. The one I have in mind is
> >>>>>>> close to the chopping block already.
> >>>>>>>
> >>>>>>> In particular:
> >>>>>>>
> >>>>>>> [EMAIL PROTECTED] F-7]$ cvs diff -u autofs.spec
> >>>>>>> Index: autofs.spec
> >>>>>>> ===================================================================
> >>>>>>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
> >>>>>>> retrieving revision 1.221
> >>>>>>> diff -u -r1.221 autofs.spec
> >>>>>>> --- autofs.spec 21 Dec 2007 10:21:18 -0000 1.221
> >>>>>>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
> >>>>>>> @@ -127,7 +127,7 @@
> >>>>>>> %patch35 -p1
> >>>>>>> %patch36 -p1
> >>>>>>> %patch37 -p1
> >>>>>>> -%patch38 -p1
> >>>>>>> +#%patch38 -p1
> >>>>>>> %patch39 -p1
> >>>>>>>
> >>>>>>> %build
> >>>>> _______________________________________________
> >>>>> autofs mailing list
> >>>>> [email protected]
> >>>>> http://linux.kernel.org/mailman/listinfo/autofs
>
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
