Bug 193718 - autofs - 'reload' does not work
autofs - 'reload' does not work
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-31 15:35 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: utofs-5.0.0_beta4-11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-15 20:39:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Remove premature return from hup signal handler (443 bytes, text/x-patch)
2006-06-07 10:34 EDT, Ian Kent
no flags Details

  None (edit)
Description Michal Jaegermann 2006-05-31 15:35:24 EDT
Description of problem:

After changes in /etc/auto.master (say, I was trying '-host' with /net
which does not work in this moment) trying to reload with

   service autofs reload

does not seem to be doing anything, i.e. whatever was a status before
edits it is retained.  OTOH 'service autofs restart' makes autofs to
notice that something did change.

Version-Release number of selected component (if applicable):
autofs-5.0.0_beta3-6
Comment 1 Ian Kent 2006-06-06 09:59:44 EDT
(In reply to comment #0)
> Description of problem:
> 
> After changes in /etc/auto.master (say, I was trying '-host' with /net
> which does not work in this moment) trying to reload with
> 
>    service autofs reload
> 
> does not seem to be doing anything, i.e. whatever was a status before
> edits it is retained.  OTOH 'service autofs restart' makes autofs to
> notice that something did change.
> 
> Version-Release number of selected component (if applicable):
> autofs-5.0.0_beta3-6

Hi Michal,

I think you mentioned this previously.
I haven't got to work on this yet .. but I will soon.

Ian


Comment 2 Ian Kent 2006-06-07 10:34:40 EDT
Created attachment 130681 [details]
Remove premature return from hup signal handler
Comment 3 Ian Kent 2006-06-07 10:40:56 EDT
I've only quickly looked at this so far but I found an error
and have posted the patch above.

Basically, at some point in the recent past I added a return
when I shouldn't and consequently a mutex is not unlocked.
This causes quite different symptoms than you report so I'm
not sure how much difference this will make.

If you have time to test the patch we can get a quick
turnaround.

Ian
Comment 4 Michal Jaegermann 2006-06-07 14:16:22 EDT
I am afraid that a patch from comment #2, applied on the top of
autofs-5.0.0_beta4-3.1, did not change anything here.  Debug output
is also not very revealing.  It basically says "exports lookup failed..."
before and after an attempt to reload maps even if after a restart
with the most recent configuration automount finds filesystems to mount.

Do you have troubles to reproduce the issue locally?

BTW - playing with reload looks like a reliable way to produce
segfaults like those discussed in 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193340#c8
and further comments.  Here is a recipe:
- with running automount edit /etc/auto.master; this looks like
  a required step although edits in other maps may possibly do
- run 'service autofs reload'
- after this quite likely automount segfaulted

Pretty quickly I accumulated three cores of that sort.  Here is
a backtrace from gdb (consistent in all instances):

(gdb) where
#0  master_mount_mounts (master=Variable "master" is not available.
) at master.c:931
#1  0x000055555556f03e in master_read_master (master=0x5555557792c0,
    age=1149703748, readall=1) at master.c:694
#2  0x000055555555ba16 in do_read_master (arg=Variable "arg" is not available.
) at automount.c:996
#3  0x00002aaaaabcc2e7 in start_thread () from /lib64/libpthread.so.0
#4  0x00002aaaaaeae2dd in clone () from /lib64/libc.so.6
#5  0x0000000000000000 in ?? ()
(gdb)  list master.c:931
926
927             source = entry->maps;
928             last = NULL;
929             while (source) {
930                     if (readall)
931                             source->stale = 1;
932
933                     /* Map source has gone away */
934                     if (source->age < age) {
935                             master_free_map_source(source, 1);
(gdb)

Comment 5 Ian Kent 2006-06-08 00:13:01 EDT
(In reply to comment #4)
> I am afraid that a patch from comment #2, applied on the top of
> autofs-5.0.0_beta4-3.1, did not change anything here.  Debug output
> is also not very revealing.  It basically says "exports lookup failed..."
> before and after an attempt to reload maps even if after a restart
> with the most recent configuration automount finds filesystems to mount.

That messages is a good start.
I'm pretty sure I haven't tried reloading a "-hosts" map yet.
The patch is definitely needed but clearly not the cause of this
problem.

> 
> Do you have troubles to reproduce the issue locally?

I've only briefly looked at this so far but, after my most recent
patches I'm not seeing a problem reloading maps yet. It's early
days in the testing though.

> 
> BTW - playing with reload looks like a reliable way to produce
> segfaults like those discussed in 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193340#c8
> and further comments.  Here is a recipe:
> - with running automount edit /etc/auto.master; this looks like
>   a required step although edits in other maps may possibly do
> - run 'service autofs reload'
> - after this quite likely automount segfaulted
> 
> Pretty quickly I accumulated three cores of that sort.  Here is
> a backtrace from gdb (consistent in all instances):

Great.
I'll try this out for the segfault issue.

You probably need to be using the same update as I am for this so
I'll email you the srpm (autofs-5.0.0_beta4-4) I've pushed to
Rawhide. This one doesn't yet have the patch here so you'll need
to apply that seperately.

Ian
Comment 6 Michal Jaegermann 2006-06-08 01:13:47 EDT
> I'm pretty sure I haven't tried reloading a "-hosts" map yet.

That is not the point and even makes testing simpler in a sense.
Say you have a non-working /etc/auto.master.  You edit it to
a configuration which is ok, you do "reload" and things still
do not work until "restart" is performed.  This looks like a pretty
good test for reloading.

OTOH if "reload" caused segfault in automount then "nothing works"
result is not that surprising. :-)
Comment 7 Michal Jaegermann 2006-06-08 15:24:55 EDT
For debugging purposes only I dropped in my copy 'static' from
'check_update_map_sources()' in master.c (to make life easier for gdb).
With that and looking at a freshly produced, by the method above, core
I see segfault in

check_update_map_sources (entry=0x55555577b570, age=1149792940, readall=1)
    at master.c:931

This is the original value of 'source'
(gdb) p entry->maps
$6 = (struct map_source *) 0x555555785000
(gdb) p *$6
$7 = {type = 0x55555577ffb0 "", format = 0x2aaaab0269d0 "", age = 1149792916, 
  mc = 0x0, stale = 1, recurse = 0, depth = 0, lookup = 0x55555577b530, 
  argc = 0, argv = 0x555555785080, instance = 0x0, next = 0x60}

As the while-loop does 'source = source->next;' it is a small wonder
that this bombs out on an attempt to write to source->stale (which happens
to be at 0x80).
Comment 8 Ian Kent 2006-06-08 20:15:45 EDT
(In reply to comment #7)
> 
> As the while-loop does 'source = source->next;' it is a small wonder
> that this bombs out on an attempt to write to source->stale (which happens
> to be at 0x80).
> 

What your saying is that the next pointer in the last or next to last
element in the list has not been correctly updated at some point.

I've looked for that of course but I'll have a closer look.

Ian


Comment 9 Michal Jaegermann 2006-06-14 16:30:28 EDT
With autofs-5.0.0_beta4-11 automount at last :-) works for me as described
in documentation.  Thanks!

One note:  Instead of putting in /etc/auto.master a line like

/net -hosts [and maybe something else here]

or similar, commented out or not in distribution packages, I would
rather see

+/etc/auto.hosts

with whatever is needed in this other file.  The point is that one
may have various automount options (--timeout=..., -fstype=...) plus
assorted mount opions, like for example
'hard,intr,nodev,nosuid,rsize=16384,wsize=16384', and it is likely a
good idea not to clutter /etc/auto.master with all of that.  Also
/etc/auto.hosts may have a short comment explaining how to add such
options; with a manpage reference, of course.
Comment 10 Ian Kent 2006-06-15 20:39:44 EDT
(In reply to comment #9)
> With autofs-5.0.0_beta4-11 automount at last :-) works for me as described
> in documentation.  Thanks!
> 
> One note:  Instead of putting in /etc/auto.master a line like
> 
> /net -hosts [and maybe something else here]
> 
> or similar, commented out or not in distribution packages, I would
> rather see
> 
> +/etc/auto.hosts
> 
> with whatever is needed in this other file.  The point is that one
> may have various automount options (--timeout=..., -fstype=...) plus
> assorted mount opions, like for example
> 'hard,intr,nodev,nosuid,rsize=16384,wsize=16384', and it is likely a
> good idea not to clutter /etc/auto.master with all of that.  Also
> /etc/auto.hosts may have a short comment explaining how to add such
> options; with a manpage reference, of course.
> 

Thanks for the feedback.
I'll get to this but it's a low priority at the moment.

Ian

Note You need to log in before you can comment on or make changes to this bug.