On Tue, Mar 5, 2013 at 12:54 AM, Ian Kent <raven@xxxxxxxxxx> wrote:
> On Fri, 2013-03-01 at 18:42 -0300, Leonardo Chiquitto wrote:
>> On Fri, Mar 1, 2013 at 5:44 AM, Ian Kent <raven@xxxxxxxxxx> wrote:
>> > On Wed, 2013-02-27 at 22:49 -0300, Leonardo Chiquitto wrote:
>> >> Hello,
>> >>
>> >> I've got a bug report describing a case where AutoFS fails to read new
>> >> entries from /etc/auto.master after a SIGHUP. Although the problem
>> >> was reported in an older version of automount, it is reproducible using
>> >> the latest revision from git.
>> >>
>> >> How to reproduce:
>> >>
>> >> 1. Add at least two sources of AutoFS maps to /etc/nsswitch.conf. I've
>> >> tested only with "files nis". You don't need to configure NIS/YP, just
>> >> having it listed there in the configuration is enough.
>> >>
>> >> 2. Start the automounter with a simple /etc/auto.master:
>> >>
>> >> /nfs1 /etc/auto.test1
>> >> +auto.master
>> >>
>> >> 3. Add another entry to /etc/auto.master:
>> >>
>> >> /nfs1 /etc/auto.test1
>> >> /nfs2 /etc/auto.test2
>> >> +auto.master
>> >>
>> >> and reload the daemon. Notice that although AutoFS reads /etc/auto.test2,
>> >> /nfs2 is not created/mounted.
>> >>
>> >> 4. Try to stop the daemon cleanly (SIGTERM only). You'll notice that it won't
>> >> quit. SIGKILL is necessary.
>> >
>> > While the failure to exit when this occurs is a worry probably due to
>> > the presence of a master map entry in the list that was not acted upon.
>> > We probably should come up with way to produce this problem after the
>> > re-read problem is fixed so we can check what is actually happening.
>>
>> Understood. I'll try to write a patch to make it ignore these "partial" entries
>> when exiting.
>>
>> > In the mean time have a look at this patch.
>> >
>> > autofs-5.0.7 - fix map read fail incorrectly set on master re-read
>>
>> I tried it here and unfortunately I'm still able to reproduce the problem.
>> I haven't had time to debug it further yet, but my *impression* is that
>> when reading the entry "+auto.master" from /etc/auto.master it
>> fails with nss source "files" due to the recursion and sets read_fail to 1.
>> Next it tries with nss source "nis" and succeeds, lookup_nss_read_master()
>> returns SUCCESS and the "read_fail = 0" added to lookup_read_master()
>> is never executed.
>
> Right, I think that means that to reproduce the problem a second map
> source must be specified and the read must must succeed. I used a second
> source that failed when I did this but using one that succeeds does
> produce the bad behaviour.
>
> The principle is still the same though. I think it is not correct to
> return a failure for the self included file map since we essentially
> want to ignore that source.
>
> The problem of entries in the master map mounts list that haven't been
> completely setup is a bit more difficult to deal with. On the face of
> it, for indirect mounts, simply continuing to the next entry if it isn't
> mounted should be enough but I'm not yet clear on the implications for
> the direct map.
>
> How about trying this patch:
>
> autofs-5.0.7 - dont fail on master map self include
Hello Ian,
I just tested it and it fails differently: when reading the entry "+auto.master"
from /etc/auto.master it first tries nss source "files" and succeed (because
recursion is now handled as !failure). This makes lookup_nss_read_master()
return even earlier, not even trying the second nss source:
220 /* First one gets it */
221 head = &nsslist;
222 list_for_each(p, head) {
(...)
262 status = check_nss_result(this, result);
263 if (status >= 0) {
264 free_sources(&nsslist);
265 return status;
266 }
In my setup, this means all maps in (NIS) auto.master are not read
when AutoFS starts.
Could you reconsider the patch that adds NSS_STATUS_RECURSE?
Or there is something totally wrong in it and I'm not seeing?
Thanks again,
Leonardo
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
