Hide Forgot
Description of problem: Loading a module that modifies MANPATH from a default environment causes man pages in the default location (/usr/share/man) to be missed when man loads. Version-Release number of selected component (if applicable): man-db-2.8.4-1.fc29.x86_64 environment-modules-4.2.1-1.fc29 How reproducible: Unknown. I have been able to reproduce this using both /bin/bash and /bin/zsh as the login shell. Steps to Reproduce: 1. Comment out all environment modules loaded in ~/.zshrc or ~/.bashrc (I have not tested this with other shells); log out and log in if necessary 2. Open a terminal 3. man ls (should work fine) 4. echo $MANPATH /usr/local/share/man:/usr/share/man [zsh] OR [bash] 4. Load an environment module that prepends to MANPATH (one choice is mpi/openmpi-x86_64 if you have openmpi-devel installed) 5. echo $MANPATH /usr/share/man/openmpi-x86_64 6. man ls Actual results: No manual entry for ls Expected results: (displays ls man page) Additional info: The sequence above reproduces the bug for me on several different machines. I also got a warning message if I type "manpath" after this procedure: manpath: warning: $MANPATH set, ignoring /etc/man_db.conf /usr/share/man/openmpi-x86-_64
This issue has recently been reported upstream (https://github.com/cea-hpc/modules/issues/224) and the fix for it will be available in the next bugfix release (4.2.3) that will be out this month.
Version 4.2.3 has just been released upstream. This new bugfix version fixes this issue.
environment-modules-4.2.3-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-edc6a7a9bb
environment-modules-4.2.3-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecb9345615
environment-modules-4.2.3-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-edc6a7a9bb
environment-modules-4.2.3-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecb9345615
I updated environment-modules to 4.2.3-1.fc29 from the updates-testing repository. This solved the problem for bash, but it still exists for zsh.
environment-modules-4.2.3-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
I cannot reproduce the issue anymore, once 4.2.3 is installed (on a Fedora 28 system). When running a zsh shell (with zsh as default shell): ~% echo $MANPATH ~% module -V Modules Release 4.2.3 (2019-03-23) ~% man -w ls /usr/share/man/man1/ls.1.gz ~% module load mpi ~% echo $MANPATH :/usr/share/man/mpich-x86_64 ~% man -w ls /usr/share/man/man1/ls.1.gz Everything works as expected in my case. Could you please provide details to reproduce the issue you get.
environment-modules-4.2.3-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
Reopening---I upgraded to environment-modules-4.2.3-1.fc29, and this still happens. It appears to have been fixed in bash, just not in zsh. Steps to reproduce in zsh (zsh-5.6.2-3.fc29): % module -V Modules Release 4.2.3 (2019-03-23) % module purge % man -w ls /usr/share/man/man1/ls.1.gz % module load mpi % man -w ls No manual entry for ls % manpath manpath: warning: $MANPATH set, ignoring /etc/man_db.conf /usr/share/man/openmpi-x86_64 Oddly, this sequence works (% => zsh prompt; $ => bash prompt): % module purge % module load mpi % man ls No manual entry for ls % bash $ module list Currently Loaded Modulefiles: 1) mpi/openmpi-x86_64 2) python-sphinx/python2-sphinx $ man -w ls /usr/share/man/man1/ls.1.gz $ zsh % module list Currently Loaded Modulefiles: 1) mpi/openmpi-x86_64 2) python-sphinx/python2-sphinx % man -w ls /usr/share/man/man1/ls.1.gz % echo $MANPATH /usr/share/man:/usr/share/man/openmpi-x86_64 % exit $ echo $MANPATH /usr/share/man:/usr/share/man/openmpi-x86_64 $ man -w ls /usr/share/man/man1/ls.1.gz $ exit % echo $MANPATH /usr/share/man/openmpi-x86_64 % man -w ls No manual entry for ls It also works this way: % module purge % module load mpi % man -w ls No manual entry for ls % zsh % man -w ls /usr/share/man/man1/ls.1.gz % module purge % module load mpi % man -w ls /usr/share/man/man1/ls.1.gz % exit % man -w ls No manual entry for ls I hope that helps....
(In reply to Karl from comment #11) > Reopening---I upgraded to environment-modules-4.2.3-1.fc29, and this still > happens. It appears to have been fixed in bash, just not in zsh. Steps to > reproduce in zsh (zsh-5.6.2-3.fc29): > > % module -V > Modules Release 4.2.3 (2019-03-23) > % module purge > % man -w ls > /usr/share/man/man1/ls.1.gz > % module load mpi > % man -w ls > No manual entry for ls > % manpath > manpath: warning: $MANPATH set, ignoring /etc/man_db.conf > /usr/share/man/openmpi-x86_64 > > Oddly, this sequence works (% => zsh prompt; $ => bash prompt): > % module purge > % module load mpi > % man ls > No manual entry for ls > % bash > $ module list > Currently Loaded Modulefiles: > 1) mpi/openmpi-x86_64 2) python-sphinx/python2-sphinx > $ man -w ls > /usr/share/man/man1/ls.1.gz > $ zsh > % module list > Currently Loaded Modulefiles: > 1) mpi/openmpi-x86_64 2) python-sphinx/python2-sphinx > % man -w ls > /usr/share/man/man1/ls.1.gz > % echo $MANPATH > /usr/share/man:/usr/share/man/openmpi-x86_64 > % exit > $ echo $MANPATH > /usr/share/man:/usr/share/man/openmpi-x86_64 > $ man -w ls > /usr/share/man/man1/ls.1.gz > $ exit > % echo $MANPATH > /usr/share/man/openmpi-x86_64 > % man -w ls > No manual entry for ls > > It also works this way: > % module purge > % module load mpi > % man -w ls > No manual entry for ls > % zsh > % man -w ls > /usr/share/man/man1/ls.1.gz > % module purge > % module load mpi > % man -w ls > /usr/share/man/man1/ls.1.gz > % exit > % man -w ls > No manual entry for ls > > I hope that helps.... I have just found that Zsh is initializing the MANPATH variable to an empty value when it starts. So Modules initialization script for the zsh shell should set MANPATH to ':' (in order to preserve manpath system configuration) if MANPATH variable is found unset or empty. I have reopened the issue upstream [1] and a fix for it will be available on next bugfix release (4.2.4) [1] https://github.com/cea-hpc/modules/issues/224
Version 4.2.4 has just been released upstream. This new bugfix version fixes this issue.
environment-modules-4.2.4-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1defad0bd1
environment-modules-4.2.4-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b594fbaf97
environment-modules-4.2.4-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b594fbaf97
environment-modules-4.2.4-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1defad0bd1
Seems to be working now. Thanks!
environment-modules-4.2.4-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
environment-modules-4.2.4-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.