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 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.



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?



Anyway, for a very long time an active (ie. currently mounted)
multi-mount would be ignored on map update requests because of
potential problems with mount dependencies.

A while ago I did try hard to improve this and allow multi-mount
map entries to be updated on reload and, for the cases I tested,
it seemed to function.

But other subsequent changes could have affected this or the
version of autofs might not have those changes.


We are running autofs-5.0.7-70.el7_4.1.x86_64 on CentOS 7.4.1708 and we
cannot update to newer CentOS releases due to other restrictions
(special hardware/drivers).

Mmm ... CentOS 7.4, that's a while ago so I'm not sure if the
changes are present but I suspect they are.

So it's likely the changes made for this are not working properly.

I'll check if the changes are present (it will take a while as
I'll need to track down what those changes were first) and try
to duplicate it to see what's going on.

Since this specific issue is interfering with productive jobs on the cluster I might be prepared to build autofs from the newest sources manually for the cluster.


Ian


frank





[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