Re: Changes in indirect multi-maps don't become effective w/o autofs restart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2019-05-16 at 12:53 +0200, Frank Thommen wrote:
> 
> On 5/16/19 3:01 AM, Ian Kent wrote:
> > On Wed, 2019-05-15 at 18:00 +0200, Frank Thommen wrote:
> > > Dear all,
> > > 
> > > the autofs manpages says:
> > > 
> > > "If  an  indirect  map  is modified then the change will become
> > > effective immediately.  If an indirect map uses the browse option, the
> > > master map contains direct mount maps or the auto.master map is modified
> > > then the autofs service control reload action must be rerun to activate
> > > the changes."
> > > 
> > > However this doesn't seem true when using multi-maps:
> > > 
> > > In /etc/auto.master:
> > > 
> > >       /base/data /etc/auto.data
> > > 
> > > 
> > > In /etc/auto.data:
> > > 
> > >      # section 1
> > >      #
> > >      p1  -fstype=nfs,vers=3,sec=sys  srv:/export/p1
> > >      p2  -fstype=nfs,vers=3,sec=sys  srv:/export/p2
> > > 
> > >      # section 2
> > >      #
> > >      others   -fstype=nfs,vers=3,sec=sys \
> > >         /p3   srv:/export/p2 \
> > >         /p4   srv:/export/p4
> > > 
> > > When adding an entry
> > > 
> > >      p5  -fstype=nfs,vers=3,sec=sys  srv:/export/p5
> > > 
> > > in section 1, I can immediately change into /base/data/p2 and it is
> > > mounted.  All well.  But when I add an entry
> > > 
> > >      /p5 srv:/export/p5
> > > 
> > > to section 2, then this new entry is not accessible as
> > > /base/data/others/p5 even after a `systemctl reload autofs`.  autofs has
> > > to be completely restarted.  Unfortunately we've had many issues
> > > (crashes) with clusterjobs accessing NFS shares during autofs restarts.
> > > That's why we'd like to avoid complete autofs restart whenever possible.
> > 
> > Yes, on restart there is a window of time where automounting won't
> > be happening.
> > 
> > That can be a problem and there's little I can do about it
> > but existing mounts should continue to function fine.
> > 
> > If you have an environment that's busy enough to get caught by
> > this then you have no choice but to avoid restarts.
> 
> I wouldn't have problems avoiding starts if the reload refreshed the 
> multi-mount maps.

Tell me more about the topology of your multi-mount map entries?
Perhaps you could use a direct mount map instead for these entries,
they should update fine on reload?

The problem you may have is that the paths can't be within an
indirect mount as the multi-mount entries.

> 
> 
> > > 
> > > Can you confirm that multi-maps are not updated by autofs reloads and/or
> > > is there a way to achieve this?
> > 
> > I call these multi-mounts because there's a different construct
> > I call multi-maps.
> 
> the autofs(5) manpage calls them "multi-map" in the "EXAMPLES" section 
> and "multi-mount map" in the "FEATURES" section.  That might be a point 
> for the "Future changes to documentation" thread?

Yes, I see that, I'll fix that.

Ian




[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux