Re: automounts that reference automounts?

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

 



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




[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