Bug 1564899 - using modules breaks man path
Summary: using modules breaks man path
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openmpi
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-08 18:38 UTC by Ankur Sinha (FranciscoD)
Modified: 2019-09-18 00:02 UTC (History)
9 users (show)

Fixed In Version: openmpi-4.0.2-0.1.rc1.fc32 openmpi-4.0.2-0.2.rc1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-18 00:02:13 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1533717 0 unspecified CLOSED mpich breaks search for manual pages 2021-02-22 00:41:40 UTC

Internal Links: 1533717

Description Ankur Sinha (FranciscoD) 2018-04-08 18:38:49 UTC
Description of problem:
Activating a module breaks the man path

Version-Release number of selected component (if applicable):
environment-modules-4.1.1-1.fc28.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install a package that provides a module, such as openmpi or mpich
2. Load the module
3. Try `man man`

Actual results:
Get "No manual entry for man"

Expected results:
Man page should be available

Additional info:
Unloading the module makes all the man pages available again:

(ins)[asinha@ankur  ~]$ module list
Currently Loaded Modulefiles:
 1) python-sphinx/python2-sphinx   2) mpi/openmpi-x86_64
(ins)[asinha@ankur  ~]$ man man
No manual entry for man
Vim: Reading from stdin...

(ins)[asinha@ankur  ~]$ module unload mpi/openmpi-x86_64
(ins)[asinha@ankur  ~]$ man man
Vim: Reading from stdin...
--

On further inspection, one finds that loading the module overwrites the man path, instead of maybe appending to it?:

(ins)[asinha@ankur  ~]$ module load mpi/openmpi-x86_64
(ins)[asinha@ankur  ~]$ echo $MANPATH
/usr/share/man/openmpi-x86_64


We thought it may be a bug in the packages, but given that another user experienced it with mpich, and I'm experiencing it with openmpi, I thought maybe it's the environment_modules package. Please re-assign it to openmpi if that's where the bug is.

Thanks,
Ankur

Comment 1 Jan Synacek 2018-04-12 08:57:55 UTC
Please, try with https://bodhi.fedoraproject.org/updates/environment-modules-4.1.2-1.fc28.

Comment 2 Ankur Sinha (FranciscoD) 2018-04-12 21:16:41 UTC
Hi Jan,

It doesn't look like I fixed it:

$ env | grep MANPATH
MANPATH_modshare=/usr/share/man/openmpi-x86_64:1
MANPATH=/usr/share/man/openmpi-x86_64
$ rpm -q environment-modules
environment-modules-4.1.2-1.fc28.x86_64

Do you think it's a bug in openmpi instead maybe? The mpich maintainer pushed some fix as discussed in the other bug.

Thanks,
Ankur

Comment 3 Xavier Delaruelle 2018-04-13 05:07:38 UTC
Hi Ankur, Hi Jan,

There was some hack in previous environment-modules version (v3.2.x) that was automatically adding "/usr/share/man" to MANPATH variable when appending-path/prepending-path to it.

This hack does not exist anymore on new major version of environment-modules (v4.x). I was thinking to re-introduce the hack but it does not seem to be a good idea as it is not possible to finely control the variable with it (to clear completely MANPATH or set it to just one directory).

So I suggest to handle the inclusion of regular man paths on all modulefiles prepending or appending to MANPATH variable, if they want the regular paths to still be there once their specific path is added.

I suggest to move the ticket to openmpi to proceed like what was done for mpich.

Best regards,
Xavier

Comment 4 Michal Jaegermann 2018-04-14 22:14:40 UTC
(In reply to Xavier Delaruelle from comment #3)
> 
> There was some hack in previous environment-modules version (v3.2.x) that
> was automatically adding "/usr/share/man" to MANPATH variable when
> appending-path/prepending-path to it.

That is quite thoroughly broken too.  Maybe in not a such blatant and horrible way as the current situation but still broken.

> 
> So I suggest to handle the inclusion of regular man paths on all modulefiles
> prepending or appending to MANPATH variable, if they want the regular paths
> to still be there once their specific path is added.

Only the issue is than in the current setup MANPATH in general is NOT explicitely set but described in details in /etc/man_db.conf and setting it to point to one directory is definitely not good enough.
 
> I suggest to move the ticket to openmpi to proceed like what was done for
> mpich.

In the case of MANPATH it was possible to work around with an extra ":".  I am not sure if other possible environment variables would be so forgiving.  From my POV a handling of implicit configuration settings in environment-modules is incorrect and a loaded trap.

Comment 5 Jan Synacek 2018-04-17 08:27:26 UTC
(In reply to Michal Jaegermann from comment #4)
> (In reply to Xavier Delaruelle from comment #3)
> > 
> > There was some hack in previous environment-modules version (v3.2.x) that
> > was automatically adding "/usr/share/man" to MANPATH variable when
> > appending-path/prepending-path to it.
> 
> That is quite thoroughly broken too.  Maybe in not a such blatant and
> horrible way as the current situation but still broken.

Why? I mean, you can only do it one way or the other, there's nothing in between, really.

> In the case of MANPATH it was possible to work around with an extra ":".  I
> am not sure if other possible environment variables would be so forgiving. 
> From my POV a handling of implicit configuration settings in
> environment-modules is incorrect and a loaded trap.

I leave this desicion on Xavier/upstream. I'm not sure how other common environment variables work, but I also think that NOT setting a variable automatically is a better decision. It's what env-modules is all about.

Comment 6 Jan Synacek 2018-04-17 08:28:08 UTC
Switching component per comment 3.

Comment 7 Michal Jaegermann 2018-04-17 14:26:40 UTC
(In reply to Jan Synacek from comment #5)
> (In reply to Michal Jaegermann from comment #4)
> > (In reply to Xavier Delaruelle from comment #3)
> > > 
> > > There was some hack in previous environment-modules version (v3.2.x) that
> > > was automatically adding "/usr/share/man" to MANPATH variable when
> > > appending-path/prepending-path to it.
> > 
> > That is quite thoroughly broken too.  Maybe in not a such blatant and
> > horrible way as the current situation but still broken.
> 
> Why? I mean, you can only do it one way or the other, there's nothing in
> between, really.

Try to type on a default installation, where MANPATH is not explicitely set,

   manpath

You see only /usr/share/man in the output or something else too?  Now do 'mkdir ~/man' and type 'manpath' again.  Something changed?  Now assume that some other program either explicitely set MANPATH to something more involved (maybe using environment-modules or by editing /etc/man_db.conf and leaving MANPATH unset).  Do you still think that adding _only_ /usr/share/man
to whatever you are trying to add in your module is an not broken thing to do?  It looked to me that this was quite obvious.

Maybe adding in environment-modules an output of manpath to whatever you are trying to append would work around that but that could be too specific to a particular implementation of man-db.

Comment 8 Ankur Sinha (FranciscoD) 2018-05-16 10:07:09 UTC
Hi,

Could we get a fix for this in the openmpi package in the meantime please? One similar to the mpich one would do. 

Thanks :)

Comment 9 Ben Cotton 2019-05-02 21:42:30 UTC
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.

Comment 10 Ankur Sinha (FranciscoD) 2019-05-04 07:20:34 UTC
Hello,

Bumping version---not sure if this has been fixed?

Cheers!

Comment 11 Zbigniew Jędrzejewski-Szmek 2019-08-30 04:36:15 UTC
Fixed in rawhide.

Comment 12 Fedora Update System 2019-08-30 04:37:38 UTC
FEDORA-2019-af50f19b83 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83

Comment 13 Fedora Update System 2019-08-30 12:17:28 UTC
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.1-10.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 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-af50f19b83

Comment 14 Fedora Update System 2019-09-05 18:01:01 UTC
FEDORA-2019-af50f19b83 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83

Comment 15 Fedora Update System 2019-09-06 00:22:24 UTC
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.2-0.2.rc1.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 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-af50f19b83

Comment 16 Fedora Update System 2019-09-13 06:15:33 UTC
FEDORA-2019-af50f19b83 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83

Comment 17 Fedora Update System 2019-09-14 01:39:37 UTC
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.2-0.2.rc1.fc31, pmix-3.1.4-2.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 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-af50f19b83

Comment 18 Fedora Update System 2019-09-18 00:02:13 UTC
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.2-0.2.rc1.fc31, pmix-3.1.4-2.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.