On 4/7/22 20:14, Daire Byrne wrote:
Hi,
I'm trying to create an executable automount script that will use
overlayfs to union paths from another automount executable defined
map. But it seems like this is not automatically triggering the
required mounts.
For example, I have an executable mount that will correctly setup
these paths when accessed (auto.hosts):
/hosts/server1/blah
/hosts/server2/blah
And then I have another executable map (auto.global) that outputs
something like this:
-fstype=overlay,ro,lowerdir=/hosts/server1/blah\:/hosts/server2/blah global
If run the mount directly using "sudo mount -t overlay overlay -o
lowerdir=/hosts/server1/blah\:/hosts/server2/blah /global" it
correctly triggers the mounting of the /hosts paths first.
But if done via the executable automount script above, then it doesn't
trigger the /hosts mounts first and fails. I also can't seem to stat
or trigger the mounts of the /hosts paths in the executable autofs
script prior to outputting the overlayfs mount string.
I can however get it to trigger a mount of a /hosts path if I just try
to do a bind mount of it from another mount map.
Is this something specific to overlayfs and/or is there a limitation
on how mounts across executable autofs maps can interact and trigger
each other?
I'm not quite sure what's going on here but ...
It's been a while so I don't remember if I have limitations on map
entries triggering mounts themselves. There should be a restriction
on entries triggering mounts within the same map, it can lead to
problems, but I'm not sure I actually check for it.
A debug log might help work out what's happening and is a good place
to start.
The problem might be (actually probably) that when overlayfs walks those
paths in the options the context of automount is such that it doesn't
trigger mounts. Other automounts can be triggered by map entries but only
at specific times and only for mount location of the current automount
during the automounting procedure. That procedure basically sets the
current process to have a different process group leader so that it will be
able to perform automounts then performs an open(2) on the mount location
and finally resets the process group leader. I can tell you this process
doesn't look at paths that are present in any options and path walks
initiated
by operlayfs will probably not be done in an automount capable context.
Problem
is, if automount was to run in a context that always triggers mounts it
would
constantly see deadlocks that can't be resolved.
Ian
