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.
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
