All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Marion <mmarion@qualcomm.com>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org
Subject: Re: Seeing autofs-5.0.2 core dumping
Date: Fri, 21 Dec 2007 11:27:45 -0800	[thread overview]
Message-ID: <20071221192744.GA14860@cornholio.qualcomm.com> (raw)
In-Reply-To: <1198236856.3488.11.camel@raven.themaw.net>

On Fri, Dec 21, 2007 at 08:34:16PM +0900, Ian Kent wrote:

> There was a bug that caused the direct map to be pruned out of existence
> when a server connection failed for some reason. I don't remember seeing
> a SEGV although I wasn't paying attention to that when I worked on it.

Yeah, we're digging into trying to get more info via debugging.  The
weird thing is that every host with an issue seems to be doing the
umount/rmdir on the exact same subset of paths (about 13 out of almost
7000 entries) and I'm positive that at least 1 path was changed 2 days
ago.  Changed in that the local path is different, but the mount point
(server:/path) is the same.  So we're going to try to re-create this on
a host by hand to see if it has to do with the daemon seeing a change in
what it has cached vs what the maps now answer with.

Even a new daemon seems to show this problem eventually too (if
restarted on a host after the daemon core dumped before) so it might be
that the change can be seen between what's in /proc/mounts still vs the
ldap map entries, and can poison the new daemon too.

BTW, not positive on this yet, but it seems like setting the logging to
debug (vs verbose) in /etc/sysconfig/autofs doesn't seem to trigger the 
same logging with 5.0.2 that it did/does with 5.0.1.  

> That shouldn't be a problem except that expires and map reads will take
> much longer. If there are problems with synchronization I expect you
> will see them before most others.

Yeah, what takes a _really_ long time, but actually works well (a credit
to the autofs5 code) is that if the running daemon is dorked or dies or
whatever... you can start up a new one, and it'll parse the entire
/proc/mounts path and take over the existing mounts and such just fine.

> I would prefer to work from fully patched source if possible.

We'll be doing some testing on this as well.  Just harder for us to get
buy-in to push out an update on something this important to the compute
pool.. but if we can prove it's more stable and fixes a problem, it's
a little easier.

-- 
Mike Marion-Unix SysAdmin/Staff IT Engineer-http://www.qualcomm.com
Peggy: "12 years old and drinking a beer!?!"
Bobby: "I didn't even like it!"
Hank: "Well now you're just trying to get me mad!" ==> King of the Hill

  reply	other threads:[~2007-12-21 19:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-21  2:30 Seeing autofs-5.0.2 core dumping Mike Marion
2007-12-21 11:34 ` Ian Kent
2007-12-21 19:27   ` Mike Marion [this message]
2007-12-21 21:13     ` Mike Marion
2007-12-21 21:50       ` Mike Marion
2007-12-21 22:47       ` Mike Marion
2007-12-22  8:20         ` Ian Kent
2007-12-24  7:40           ` Mike Marion

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071221192744.GA14860@cornholio.qualcomm.com \
    --to=mmarion@qualcomm.com \
    --cc=autofs@linux.kernel.org \
    --cc=raven@themaw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.