Description of problem: If environment-modules is installed and a shell script is run with bash's xtrace option enabled, environment-modules causes copious output of its own, unrelated to the script being run. This did not occur previous releases. It is due to changes in environment-modules >= 4.0. Upstream added a variable users can set to disable most --but not all-- of this output in 4.1.0, to fix https://github.com/cea-hpc/modules/issues/121. This change comes as a surprise and seems unlikely to be desirable default behavior. I'm not a user of environment-modules, but found it was installed by default on my Fedora 28 Workstation install. It is a requirement of scl-utils, which many Fedora users won't miss, but RHEL users are more likely to want to use scl-utils and will find it harder to simply remove the environment-modules package. I would argue that by default environment-modules should not add any output of its own when running shell scripts via bash with xtrace set. At the least, the option to minimize this output should be set. That can be done with MODULES_SILENT_SHELL_DEBUG=1 (added upstream in https://github.com/cea-hpc/modules/commit/a6a93c5f). It's worth noting that this does not occur when running via 'sh -x'. 'bash -x' is required, which is less commonly used (in my experience, at least). None of the other sh-based shells I tested appear to be affected (dash, ksh, mksh, and zsh). This issue was brought up today on the fedora users list: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/VBFQMLGVPFVFV2RZDMFXNZ43HBU2CWCF/ Below follows a full example with and without environment-modules installed. Version-Release number of selected component (if applicable): environment-modules-4.1.2-2.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. Install environment-modules (installed by default on F28 Workstation) 2. Run a shell script via 'bash -x' 3. Observe copious output from environment-modules Actual results: $ cat <<\EOF >/tmp/test.sh #!/bin/sh echo "Test script output" EOF $ bash -x /tmp/test.sh + unset _mlre _mlIFS _mlshdbg + '[' 0 = 1 ']' + export MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH + MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH + '[' -n x ']' + _mlIFS=' ' + IFS=' ' + for _mlv in ${MODULES_RUN_QUARANTINE:-} + '[' LD_LIBRARY_PATH = LD_LIBRARY_PATH -a LD_LIBRARY_PATH = LD_LIBRARY_PATH ']' ++ eval 'echo ${LD_LIBRARY_PATH+x}' +++ echo + '[' -n '' ']' + _mlrv=MODULES_RUNENV_LD_LIBRARY_PATH ++ eval 'echo ${MODULES_RUNENV_LD_LIBRARY_PATH:-}' +++ echo + _mlre='LD_LIBRARY_PATH='\'''\'' ' + '[' -n 'LD_LIBRARY_PATH='\'''\'' ' ']' + _mlre='eval LD_LIBRARY_PATH='\'''\'' ' ++ eval 'LD_LIBRARY_PATH='\'''\''' /usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash autoinit +++ LD_LIBRARY_PATH= +++ /usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash autoinit + eval '_moduleraw() { unset _mlre _mlIFS _mlshdbg; if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '\''1'\'' ]; then case "$-" in *v*x*) set +vx; _mlshdbg='\''vx'\'' ;; *v*) set +v; _mlshdbg='\''v'\'' ;; *x*) set +x; _mlshdbg='\''x'\'' ;; *) _mlshdbg='\'''\'' ;; esac; fi; if [ -n "${IFS+x}" ]; then _mlIFS=$IFS; fi; IFS='\'' '\''; for _mlv in ${MODULES_RUN_QUARANTINE:-}; do if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then if [ -n "`eval '\''echo ${'\''$_mlv'\''+x}'\''`" ]; then _mlre="${_mlre:-}${_mlv}_modquar='\''`eval '\''echo ${'\''$_mlv'\''}'\''`'\'' "; fi; fi; done; if [ -n "${_mlre:-}" ]; then eval `eval ${_mlre}/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '\''"$@"'\''`; else eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`; fi; _mlstatus=$?; if [ -n "${_mlIFS+x}" ]; then IFS=$_mlIFS; else unset IFS; fi; if [ -n "${_mlshdbg:-}" ]; then set -$_mlshdbg; fi; unset _mlre _mlv _mlrv _mlIFS _mlshdbg; return $_mlstatus; }; module() { _moduleraw "$@" 2>&1; }; MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl; export MODULES_CMD; MODULESHOME=/usr/share/Modules; export MODULESHOME; test 0;' ++ MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl ++ export MODULES_CMD ++ MODULESHOME=/usr/share/Modules ++ export MODULESHOME ++ test 0 + '[' -n x ']' + IFS=' ' + unset _mlIFS + unset _mlre _mlv _mlrv + '[' 0 = 1 ']' + '[' -t 1 ']' + export -f _moduleraw + export -f module + export -f switchml + ENV=/usr/share/Modules/init/profile.sh + export ENV + BASH_ENV=/usr/share/Modules/init/bash + export BASH_ENV + '[' 4 -ge 3 ']' + [[ hxB =~ i ]] + [[ ! :/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/test/.local/bin:/home/test/bin: =~ :/usr/share/Modules/bin: ]] ++ manpath + manpath=/usr/local/share/man:/usr/share/man + [[ ! :/usr/local/share/man:/usr/share/man: =~ :/usr/share/man: ]] + '[' -n '' ']' + echo 'Test script output' Test script output Expected results: $ bash -x /tmp/test.sh + echo 'Test script output' Test script output Additional info: When run with MODULES_SILENT_SHELL_DEBUG=1 set, the output is better, but still contains shell tracing from environment-modules which is not relevant. $ MODULES_SILENT_SHELL_DEBUG=1 bash -x /tmp/test.sh + unset _mlre _mlIFS _mlshdbg + '[' 1 = 1 ']' + case "$-" in + set +x + unset _mlshdbg + echo 'Test script output' Test script output
Looking closer, environment-modules is pulled in because scl-utils is part of the workstation-product group (and as been since at least f21). It's part of the base group in RHEL-7. I think the change in environment-modules is undesirable, but I'm not sure what the best solution may be. While it might be an option to drop scl-utils from the workstation group on Fedora, that doesn't solve the problem so much as hides it. RHEL seems less likely to want to drop scl-utils from the default install. Ideally, I think the debugging should be disabled by default upstream and done in a way that doesn't clutter the output even as much as when MODULES_SILENT_SHELL_DEBUG=1 is set.
Get the same output using 'sh -v " to run a script
I've encountered another perhaps related problem caused by environment-modules.... I have a very complex Makefile that invokes the shell a lot, even when making a target that is up to date. When I upgraded to Fedora 29 from 27, these make invocations went from taking 4 seconds to 20. I eventually worked out that this was caused by bash invoking /usr/share/Modules/init/bash and hence "/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl". This is an expensive thing to do for every bash invocation and I don't know if it is really necessary for non-interactive shells, such as those started by make. Rather than uninstalling environment-modules - unsure as I was as to why it had been installed by updating Fedora, I worked around the problem with this snippet in my Makefile: unexport ENV unexport BASH_ENV In my opinion, environment-modules should not seek to influence the environment of non-interactive shells. At least, not by default. It seems to be designed for interactive use - as far as I can tell from its documentation.
Actually, many scripts and jobs may need to load modules in order to run properly. So it's not just for interactive shells.
Those scripts will inherit the exported environment from an interactive parent shell, or can invoke the modules system explicitly if running from cron or similar. I'm suggesting that the use of BASH_ENV may be an unexceptablely expensive default.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still a problem in 29
still a problem in 30
*** Bug 1707812 has been marked as a duplicate of this bug. ***
New release of environment-modules introduces the ability to control whether or not shell startup file should be set to ensure module command is defined once shell has been initialized. When enabled, the ENV and BASH_ENV environment variables are set, when module function is defined, to the Modules bourne shell initialization script. When disabled both ENV and BASH_ENV are left untouched. Prior version 4.3.0 this "set shell startup file" mechanism was enabled by default. The 4.3.0 package built for Fedora (bug #1733752) sets the `--disable-set-shell-startup` configure option which disables the mechanism by default. If a sysadmin want the mecanishm enabled, he/she could enable it by adding the `module config set_shell_startup 1` line to the /etc/environment-modules/initrc configuration file. This change should fix the issue described here.
environment-modules (and scl-utils) was installed automatically in Fedora 31 as well - removing those packages made these superfluous environment variables go away. Why these were installed in the first place on a workstation is beyond me though :)
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Whatever environment-modules is doing, it shouldn't come preinstalled and I remember uninstalling it for the same reason a while back. Right now, on Fedora 31 I can't reproduce this any more: $ dnf install environment-modules $ rpm -q environment-modules environment-modules-4.3.0-1.fc31.x86_64 $ bash -x /tmp/test.sh + echo 'Test script output' Test script output
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.