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
(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
Created attachment 130681 [details] Remove premature return from hup signal handler
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
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)
(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
> 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. :-)
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).
(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
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.
(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