Description of problem: It seems that "module unload <modulefile>" works only if <modulefile> is inside of /usr/share/Modules/modulefiles/ (and probably also /etc/modulefiles, didn't test this) Version-Release number of selected component (if applicable): environment-modules-3.2.6-7.fc11.x86_64 How reproducible: Always Steps to Reproduce: >module load /usr/share/mpich2/mpich2.module >module list Currently Loaded Modulefiles: 1) /usr/share/mpich2/mpich2.module >module unload /usr/share/mpich2/mpich2.module >module list Currently Loaded Modulefiles: 1) /usr/share/mpich2/mpich2.module >module purge >module list No Modulefiles Currently Loaded. >cp /usr/share/mpich2/mpich2.module /usr/share/Modules/modulefiles/ >module load mpich2.module >module list Currently Loaded Modulefiles: 1) mpich2.module >module unload mpich2.module >module list No Modulefiles Currently Loaded. Additional info: Though I'm aware that modulefiles should be present in standard directories, this should imho work too.
This works (at least with 3.2.7b): [orion@orca devel]$ module load /usr/share/mpich2/mpich2-32 [orion@orca devel]$ module list Currently Loaded Modulefiles: 1) /usr/share/mpich2/mpich2-32 [orion@orca devel]$ module unload mpich2-32 [orion@orca devel]$ module list No Modulefiles Currently Loaded. How's that?
Ah, it reveals that this is not a bug, I pointed to the modulefile via an absolute path when unloading (like when loading it), which doesn't work, one has to pass just the filename as argument as you did. However, the "module unload <name>" command returns 0 whatever nonsense is passed as <name>, which is not good (it should print an error). There is another issue with the update to 3.2.7b, namely that the path to modulecmd in /etc/profile.d/modules.sh is now wrong (commented on the update).
(In reply to comment #2) > However, the "module unload <name>" command returns 0 whatever nonsense is > passed as <name>, which is not good (it should print an error). True, but this should be filed upstream. > There is another issue with the update to 3.2.7b, namely that the path to > modulecmd in /etc/profile.d/modules.sh is now wrong (commented on the update). Yes, fixed in 3.2.7b-2. Thanks.
(In reply to comment #3) > (In reply to comment #2) > > However, the "module unload <name>" command returns 0 whatever nonsense is > > passed as <name>, which is not good (it should print an error). > > True, but this should be filed upstream. Just FYI, I found this already file as: https://sourceforge.net/tracker/?func=detail&aid=2384340&group_id=15538&atid=115538 ...commented on the bug.