Hi all
TL;DR Can it be considered to replace coreutils command calls (such as "id -u" and "uname -s") in /usr/share/lmod/lmod/init/* with full paths to the executables (e.g. either using "/usr/bin/id" or "/bin/id" or "command -p id")? This solves issues where the PATH environment variable was prepended with a path that also contains commands with the same name as the standard coreutils commands.
I came across an issue with using Lmod and hpc-container-wrapper (Tykky). When creating a container with conda-rontainerize it creates a container and a bin directory with wrapper scripts to executables inside the container. When the wrapper script is called, it actually starts the container and executes the executable inside the container.
But when the container contains the coreutils package, wrappers for "id" and "uname" (amongst others) are also created. And then, when we extend PATH to include the bin directory of the container, this results in the wrappers being called instead when just using $(id -u) or $(uname -s) respectively.
And this gives an issue with the (our) default Lmod installation. We are using bash as the default shell.
It uses /etc/profile.d/modules.sh which points to /usr/share/lmod/lmod/init/profile which sets BASH_ENV=/usr/share/lmod/lmod/init/bash. As such, subsequently, when scripts are called, the script in BASH_ENV is executed too. In this script (BASH_ENV) both $(id -u) and $(uname -s) are called, but because we extended PATH, the scripts (from the container bin) directory are called, and so on ... we end up with an infinite chain of sshd───bash───lmod───sh───stty───id───id───id───id───id───id───id... (as seen in the output from pstree).
If Lmod would be using the full paths to all the coreutils commands, then this issue would not appear. The coreutils commands are usually in a fixed path (either /bin or /usr/bin) or a command could be used to find it (e.g., in bash: command -p). Therefore, I hope that you could consider my suggestion...
-- Kind regards
Franky Backeljauw
Universiteit Antwerpen
Hi all
TL;DR Can it be considered to replace coreutils command calls (such as "id -u" and "uname -s") in /usr/share/lmod/lmod/init/* with full paths to the executables (e.g. either using "/usr/bin/id" or "/bin/id" or "command -p id")? This solves issues where the PATH environment variable was prepended with a path that also contains commands with the same name as the standard coreutils commands.
I came across an issue with using Lmod and hpc-container-wrapper (Tykky). When creating a container with
conda-rontainerizeit creates a container and a bin directory with wrapper scripts to executables inside the container. When the wrapper script is called, it actually starts the container and executes the executable inside the container.But when the container contains the
coreutilspackage, wrappers for "id" and "uname" (amongst others) are also created. And then, when we extend PATH to include the bin directory of the container, this results in the wrappers being called instead when just using$(id -u)or$(uname -s)respectively.And this gives an issue with the (our) default Lmod installation. We are using
bashas the default shell.It uses
/etc/profile.d/modules.shwhich points to/usr/share/lmod/lmod/init/profilewhich setsBASH_ENV=/usr/share/lmod/lmod/init/bash. As such, subsequently, when scripts are called, the script inBASH_ENVis executed too. In this script (BASH_ENV) both$(id -u)and$(uname -s)are called, but because we extended PATH, the scripts (from the container bin) directory are called, and so on ... we end up with an infinite chain ofsshd───bash───lmod───sh───stty───id───id───id───id───id───id───id...(as seen in the output frompstree).If Lmod would be using the full paths to all the coreutils commands, then this issue would not appear. The coreutils commands are usually in a fixed path (either
/binor/usr/bin) or a command could be used to find it (e.g., in bash:command -p). Therefore, I hope that you could consider my suggestion...-- Kind regards
Franky Backeljauw
Universiteit Antwerpen