build.sh: add option to build in a 'bind-mount' directory

[thomas]

This is way experimental. Trouble might arise from the
automounter when it comes to expiring the wrong directory
(the one bound).

[donald]

Suggestions to consider:

• Don't use the directory specified by --bind directly, but create a subdirectory in it and use that instead. Would reduce bad effects of suboptimal command usage (--bind . --purge, --bind /tmp)

• Do the mount first, so we don't need the special code for the purge part?

• Do not try to understand mount tree and use grep. Just probe, if the path resolves to the target. e,g. (untested):

     mkdir -p $MOUNTPOINT
     test "$(stat --format "%D:%i") $MOUNTPOINT" =  "$(stat --format "%D:%i") $DIRECTORY" || mount --bind $DIRECTORY $MOUNTPOINT

• I think the chown bin:bin after the cp -ain the very last line of the script is not needed.
• We could 'lock' the path from auto-unmounting ( e.g. fork a process, which cds into the target, checks again, it is still the right one and sleep infinitys in it), but I don't think we really need that. Under normal operations, the time window between the commands should be much to small to expect the automounter to intervene. If it happens, the fact that we can't write to /pkg/$PKG should prevent bad things to happen.

[thomas]

• (1) agree, didn't consider other usages as --bind /tmp/my_bound_dir :)

• (2) Right now I'm not shure what happens when I mount over an un-mounted amd path. So I play safe and look on for other unexpected surprises, then this one is to be tackled?

• (3) LGTM

• (4) It's needed insofar, as the purge test at the start checks for the build user. Maybe purging needs a little rework.

• (5) I'm stil curious about this, but I guess as long as the build script 'sits' (has 'cd'-ed) in its build/install dir, this should be sufficient to inhibit unmounting?

[donald]

I'm stil curious about this, but I guess as long as the build script 'sits' (has 'cd'-ed) in its build/install dir, this should be sufficient to inhibit unmounting?

Thats right. A process with cwd in it will prevent unmounting, so it will not go away while building.

OMG, stupid me, its even easier: Instead of forking (and killing!) a separate process, the script can just open the directory to prevent unmouting. This will automatically go away when the script terminates.

Untested:

if [ "$(stat --format "%D:%i") $MOUNTPOINT" != "$(stat --format "%D:%i") $DIRECTORY" ]; then
    mount --bind $DIRECTORY $MOUNTPOINT
    exec 3<$MOUNTPOINT/.    # prevent automount from unmounting
    test "$(stat --format "%D:%i") $MOUNTPOINT" = "$(stat --format "%D:%i") $DIRECTORY" || die "unable to mount and lock $DIRECTORY on $MOUNTPOINT"
fi

If the second test doesn't die, we can be sure that it is and will stay mounted.

[donald]

Right now I'm not shure what happens when I mount over an un-mounted amd path.

My guess would be, this would trigger an automount first on which the other mount goes on top. Going to test this in a minute, but wanted to make a bet first.

[thomas]

Guess your bet is right, at least if I interpret my results correctly :)

[donald]

not really....

buczek@deadbird:~$ findmnt /home/molgen
buczek@deadbird:~$ findmnt /home/molgen
buczek@deadbird:~$ sudo mount --bind /tmp /home/molgen
buczek@deadbird:~$ findmnt /home/molgen
TARGET       SOURCE          FSTYPE OPTIONS
/home/molgen /dev/sda1[/tmp] xfs    rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

Anyway, our script down't care, whether there is a nfs mount below the bind mount or not. :-)

[thomas]

Sure that findmnt didn't trigger the automounter ?

addendum:

I got the sense of the double findmount, but I saw:

[root@suse:~]
#ls /pkg
[root@suse:~]
#findmnt /pkg/python-3.9.0-0
[root@suse:~]
#ls /pkg
python-3.9.0-0
[root@suse:~]

[thomas]

I've checked via the existance of /pkg/python-3.9.0-0. /pkg was empty, mount -B /dev/shm/bla /pkg/python-3.9.0-0, all fine. umount /pkg/python-3.9.0-0, python content is there. After some time /pkg was empty again.

[donald]

Yes, I made an error: When repeating the test, I wasn't patient enough to wait for the automounter to expire the path, but manually used umount on it. The big difference is, that I left the mountpoint directory in place, while the automounter would usually remove that, too, after the umount.

If there is no /home/molgen directory and I use findmnt /home/molgen or mount --bind /tmp /home/molgen, that will trigger an automount first.

If, on the other hand, there is an (unmounted) local directory /home/molgen , than both commands do not trigger an automount.

At least I can claim, that my first prognosis was correct :-)

And, again, we don't really care in this case, as the possible mount done by automount would be covered by our own manual mount anyway.

[donald]

Still "not ready for merge"? I didn't test it, but if you did and it works, its okay for my part. Go ahead and merge when ready.