Lmod changes?

[mathog]

There seem to be a lot of differences between Lmod on CO7 and CO8, which is odd since it looks like the same version of that program:

Code: Select all

#CO7
rpm -qa | grep Lmod
Lmod-8.2.7-1.el7.x86_64
set | grep -i module | head -4
LOADEDMODULES=
MODULEPATH=/usr/common/modules/el7/x86_64/modules/all:/etc/modulefiles:/usr/share/modulefiles:/usr/share/modulefiles/Linux:/usr/share/modulefiles/Core:/usr/share/lmod/lmod/modulefiles/Core
MODULEPATH_ROOT=/usr/share/modulefiles
MODULESHOME=/usr/share/lmod/lmod
rpm -q --whatprovides /usr/share/Modules
environment-modules-3.2.10-10.el7.x86_64
ls -al /etc/profile.d/z00*
lrwxrwxrwx. 1 root root 31 Dec 16 02:17 /etc/profile.d/z00_lmod.csh -> /usr/share/lmod/lmod/init/cshrc
lrwxrwxrwx. 1 root root 33 Dec 16 02:17 /etc/profile.d/z00_lmod.sh -> /usr/share/lmod/lmod/init/profile
rpm -q --whatprovides  /etc/profile.d/z00_lmod.csh
Lmod-8.2.7-1.el7.x86_64

#CO8
rpm -qa | grep Lmod
Lmod-8.2.7-1.el8.x86_64
set | grep -i module | head -6
BASH_ENV=/usr/share/Modules/init/bash
ENV=/usr/share/Modules/init/profile.sh
LOADEDMODULES=
MODULEPATH=/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles
MODULEPATH_modshare=/usr/share/modulefiles:1:/etc/modulefiles:1:/usr/share/Modules/modulefiles:1
MODULESHOME=/usr/share/Modules
rpm -q --whatprovides /usr/share/Modules
environment-modules-4.1.4-4.el8.x86_64
ls -al /etc/profile.d/z00*
ls: cannot access '/etc/profile.d/z00*': No such file or directory

On CO7 the only customization was to modify the "/etc/profile.d/00-module*" files to add the /usr/common path. The same modification was made on the CO8 system and it was completely ignored. CO8 has the /usr/share/lmod/lmod and /usr/share/lmod/8.2.7/init contents (except for fish_tab_completion in the latter, which differs in size by 1 byte).

It looks like "environment-modules" has somehow or other rearranged how lmod works, changing MODULESHOME and apparently the init method somethow. Why? Or better, how? I still need to redirect to my own MODULEPATH but the previous method apparently no longer works.

[mathog]

Ah, there are alternatives on CO8.

Code: Select all

alternatives --config modules.sh

There are 2 programs which provide 'modules.sh'.

  Selection    Command
-----------------------------------------------
   1           /usr/share/lmod/lmod/init/profile
*+ 2           /usr/share/Modules/init/profile.sh

Selecting the first one makes the changes to /etc/profile.d/00*sh active, so that the modules at that path are seen.
This also makes the variables set more like on CO7, although scl-utils is now somehow prepending in /etc/scl/modulefiles which it did not do under CO7.

[mathog]

Correction, SCL is appending twice to MODULESPATH:

Code: Select all

echo $MODULEPATH
/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/common/modules/el8/x86_64/modules/all:/usr/common/modules/el7/x86_64/modules/all:/etc/modulefiles:/usr/share/modulefiles:/usr/share/modulefiles/Linux:/usr/share/modulefiles/Core:/usr/share/lmod/lmod/modulefiles/Core

Not sure why it does that twice. In any case, at present /etc/scl/modulefiles is empty, so all it will do is slow down some of the module operations slightly.

[mathog]

There are other differences in behavior too. The "cache" settings on both are:

Code: Select all

module --config 2>&1 | grep -i cache
number of cache dirs               0
Ignore Cache                       no
Cached loads                       no
User cache valid time(sec)         86400
Write cache after (sec)            2

On CentOS 8 this exists:

Code: Select all

ls -al ~/.lmod.d/.cache
total 472
drwxrwxr-x. 2 modules modules     75 Jun 19 14:31 .
drwxrwxr-x. 3 modules modules     20 Jun 19 14:31 ..
-rw-rw-r--. 1 modules modules 271979 Jun 19 14:31 spiderT.x86_64_Linux.lua
-rw-rw-r--. 1 modules modules 206631 Jun 19 14:31 spiderT.x86_64_Linux.luac_5.3

If .lmod.d is deleted and the command "module avail" run then these cache files are regenerated. However on CentOS 7 they need not exist and they will not be created by the same command. If that directory is absent on 8 it is created by "module avail" but the cache may not be updated in other circumstances, which results in

Code: Select all

module avail

sometimes not showing a module which has recently been added, but

Code: Select all

module --ignore_cache avail

will show it. Unclear why the cache is being referenced at all since it seems to think there are no cached directories. I have looked high and low for the difference which is causing this, but the only changes seen between CentOS 7 and CentOS 8 are in the installed versions of Lua and TCL.

Is this just my system or do others see this too?

[mathog]

This system has these RPMS

Code: Select all

gcc-toolset-9* 

which in turn required this:

Code: Select all

scl-utils-1:2.0.2-11.el8.x86_64

which in turn required this:

Code: Select all

environment-modules-4.1.4-4.el8.x86_64

That last one appears to be another implementation of Lmod, which perhaps was not already installed when gcc-toolset was put on. Currently though this is also installed

Code: Select all

Lmod-8.2.7-1.el8.x86_64

and these last two end up both listed in alternatives for "module.sh". Maybe removing environment-modules and reinstalling gcc-toolset will not reinstall environment-modules? (That is, if it sees Lmod, it will accept it?)

Code: Select all

dnf remove environment-modules
Removing:
 environment-modules             x86_64 4.1.4-4.el8            @BaseOS    1.0 M
Removing dependent packages:
 gcc-toolset-9-binutils          x86_64 2.32-15.el8            @AppStream  29 M
 gcc-toolset-9-gcc               x86_64 9.1.1-2.4.el8          @AppStream  75 M
 gcc-toolset-9-gcc-c++           x86_64 9.1.1-2.4.el8          @AppStream  31 M
 gcc-toolset-9-gcc-gdb-plugin    x86_64 9.1.1-2.4.el8          @AppStream 338 k
 gcc-toolset-9-gcc-gfortran      x86_64 9.1.1-2.4.el8          @AppStream  38 M
 gcc-toolset-9-gdb               x86_64 8.3-1.el8              @AppStream  15 M
 gcc-toolset-9-valgrind-devel    x86_64 1:3.15.0-9.el8         @AppStream 464 k
Removing unused dependencies:
 gcc-toolset-9-libquadmath-devel x86_64 9.1.1-2.4.el8          @AppStream 681 k
 gcc-toolset-9-libstdc++-devel   x86_64 9.1.1-2.4.el8          @AppStream  18 M
 gcc-toolset-9-runtime           x86_64 9.0-3.el8              @AppStream 3.2 k
 gcc-toolset-9-valgrind          x86_64 1:3.15.0-9.el8         @AppStream  35 M
 policycoreutils-python-utils    noarch 2.9-3.el8_1.1          @BaseOS    137 k
 python3-audit                   x86_64 3.0-0.13.20190507gitf58ec40.el8
                                                               @BaseOS    346 k
 python3-policycoreutils         noarch 2.9-3.el8_1.1          @BaseOS    5.4 M
 python3-setools                 x86_64 4.2.2-1.el8            @BaseOS    2.6 M
 scl-utils                       x86_64 1:2.0.2-11.el8         @AppStream  78 k

#logged into a fresh "modules" session
module avail
#it updates ~/.lmod.d
rm -rf ~/.lmod.d
modules avail
#it does NOT recreate ~/.lmod.d
#as root
dnf -y install \
 gcc-toolset-9-binutils \
 gcc-toolset-9-gcc \
 gcc-toolset-9-gcc-c++ \
 gcc-toolset-9-gcc-gdb-plugin \
 gcc-toolset-9-gcc-gfortran \
 gcc-toolset-9-gdb \
 gcc-toolset-9-valgrind-devel \
 gcc-toolset-9-libquadmath-devel \
 gcc-toolset-9-libstdc++-devel \
 gcc-toolset-9-runtime \
 gcc-toolset-9-valgrind
#it reinstall environment-modules too
#as new session of modules
module avail
#it does NOT recreate ~/.lmod.d

Apparently not, it installs environment-modules even when Lmod is already present.

That remove and reinstall _may_ have fixed the unwanted spider runs. However I won't really trust that that is the case until some time has passed, as it might have stored the last spider run time somewhere and be waiting for 24 hours to expire.

[mathog]

One last oddity,

Code: Select all

rpm --verify environment-modules
#nothing noted
rpm -q --filesbypkg environment-modules | grep modulecmd
environment-modules       /usr/bin/modulecmd
environment-modules       /usr/share/Modules/libexec/modulecmd.tcl
ls -al /usr/bin/modulecmd
ls: cannot access '/usr/bin/modulecmd': No such file or directory
ls -al /usr/share/Modules/libexec/modulecmd.tcl
-rwxr-xr-x. 1 root root 213252 Nov  8  2019 /usr/share/Modules/libexec/modulecmd.tcl