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
