Currently, when a Guix program runs in separate user, mount, and PID namespaces (for example via (guix least-authority)), ‘guix container exec’ fails badly:
guix container exec 10652 /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8/bin/sh guix container: error: process terminated with signal 11 or, similarly: nsenter --preserve-credentials -U -m -t 10652 -m -U -p -F /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8/bin/sh Segmentation fault Stracing reveals that the child process segfaults immediately after attempting to read /proc/self/exe: 14111 readlink("/proc/self/exe", 0x7ffccefa29c0, 4096) = -1 ENOENT (No such file or directory) 14111 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffffffffff} --- The segfault is due to <https://issues.guix.gnu.org/52671>. But why isn’t /proc visible in the first place? It *is* definitely mounted within that process’s namespace, as confirmed here: $ ls -ld /proc/10652/root/proc dr-xr-xr-x 326 root root 0 Jan 29 21:55 /proc/10652/root/proc/ The reason is that calling setns(2) on a PID namespace “changes only the PID namespace that subsequently created child processes of the caller will be placed in; it does not change the PID namespace of the caller itself.” This is why removing ‘-F’ in the ‘nsenter’ command line above solves the problem. Conclusion: ’container-excursion’ should fork so that the PID namespace change takes effect. Ludo’.