Automatic PROOT_NO_SECCOMP

[dtrudg]

Is your feature request related to a problem? Please describe.

In certain circumstances, proot may not operate correctly. E.g. newest RHEL 7 kernels, without setting the env var PROOT_NO_SECCOMP.

Describe the solution you'd like

Following on from #879 we should aim to streamline the process of using proot by setting the environment variable PROOT_NO_SECCOMP if an initial execution of proot fails.

We could either:

• use a canary execution with proot, e.g. running /bin/true through proot before we run def file scripts, to ascertain whether PROOT_NO_SECCOMP should be used -or-
• just retry executing with PROOT_NO_SECCOMP if the def file script execution fails with an appropriate error code.

The first (canary) approach is encouraged, as it avoids the def file execution returning an error that could be confused for a proot failure.

We should not set PROOT_NO_SECCOMP by default, as seccomp support provides significant performance improvements for proot.

Additional context

See #879 (comment) for some discussion.

See the changes in PR #879 in the build code for the location in which proot is used, and this PROOT_NO_SECCOMP handling needs to take effect.

[dtrudg]

It appears the issue is a regression in latest proot, as it should auto detect whether to use seccomp or not - proot-me/proot#336

[dtrudg]

Since this is clearly a regression in proot, not a SingularityCE problem, and is tracked in their repo, I'm going to drop this from the 3.11 milestone, and will list the issue in errata.

We have quite a lot of code that is checking function of external binaries in brittle ways, and I'm keen not to add any more at this time. If it becomes a very large issue then it could be reconsidered for a 3.11.x patch release.