lmod-users — A list to discuss using/deploying Lmod

Re: [Lmod-users] Difference between bash and cshell for source_sh

[Robert M. <rt...@gm...>]

Since you have not received a response, it would seem that no one else has
solved the problem either.

Please create an issue at github with this.  In this issue please report
what the output of the following is:

bash> $LMOD_CMD csh load conda 2>&1 > conda_load.log
bash> $LMOD_CMD csh load conda_env 2>&1 > conda_env_load.log
bash> $LMOD_CMD csh load conda conda_env 2>&1 > big_conda_load.log

Please attach the above three log files to the github issue.

Thanks,
Robert.


On Mon, Mar 16, 2026 at 10:56 AM Jakob Stierhof <jak...@fa...>
wrote:

> Dear Lmod users,
>
> at our site we provide the users with a conda installation via lmod.
> While this works fine, we also have some locally compiled code that
> depends on python and we use conda environments for it. We managed to
> activate and deactivate a specific conda env via a module file doing
> nothing else other than having a `execute{cmd='conda activate {env}',
> modeA={'load'}}` and correspondingly for unload.
>
> This works as expected in the shell (provided the conda module is loaded
> and not requiested via, e.g., `depends_on`, i.e., set as `prereq`).
> However, when the module for the conda environment is used in another
> module file it does work as expected using bash, but it fails for cshell.
>
> The problem is not because of lmod, but because how conda initializes
> for bash or cshell. In the latter case the `conda activate` throws an
> error `CondaError: Run 'conda init' before 'conda activate`. I suspect
> that the way how lmod modifies the environment interferes with how conda
> wants it to be when running.
>
> So, in short:
>
> cshell> module load conda
> cshell> module load conda_env
>
> works, while
>
> cshell> module load conda conda_env
>
> does not.
>
> For bash, both work just fine.
>
> I was wondering if someone tried to solve a similar issue and came up
> with a good solution.
>
> Thanks!
> Jakob
>
>
>
> _______________________________________________
> Lmod-users mailing list
> Lmo...@li...
> https://lists.sourceforge.net/lists/listinfo/lmod-users
>

[Lmod-users] Difference between bash and cshell for source_sh

[Jakob S. <jak...@fa...>]

Dear Lmod users,

at our site we provide the users with a conda installation via lmod. 
While this works fine, we also have some locally compiled code that 
depends on python and we use conda environments for it. We managed to 
activate and deactivate a specific conda env via a module file doing 
nothing else other than having a `execute{cmd='conda activate {env}', 
modeA={'load'}}` and correspondingly for unload.

This works as expected in the shell (provided the conda module is loaded 
and not requiested via, e.g., `depends_on`, i.e., set as `prereq`). 
However, when the module for the conda environment is used in another 
module file it does work as expected using bash, but it fails for cshell.

The problem is not because of lmod, but because how conda initializes 
for bash or cshell. In the latter case the `conda activate` throws an 
error `CondaError: Run 'conda init' before 'conda activate`. I suspect 
that the way how lmod modifies the environment interferes with how conda 
wants it to be when running.

So, in short:

cshell> module load conda
cshell> module load conda_env

works, while

cshell> module load conda conda_env

does not.

For bash, both work just fine.

I was wondering if someone tried to solve a similar issue and came up 
with a good solution.

Thanks!
Jakob

[Lmod-users] Lmod Zoom Mtg March 3rd, 2026

[Matthew C. <mc...@ta...>]

We will hold the next Lmod Zoom meeting on March 3rd at 9:30 US Central Time (15:30 UTC).

The current agenda is:

  *
Issue #805: suggestion follow-up
  *
Issue #806: fix installed library files
  *
Issue #807: Lua 5.5 support
  *
Issue #808: describe() support for collections
  *
main: improved multiline “unknown error” messaging for multi-module requests (prereq-load hint)
  *
User Q&A

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The Zoom link is:
https://utexas.zoom.us/my/mcawood

Best,
Lmod Team

[Lmod-users] Tomorrow: Lmod Monthly Zoom Meeting at 9:30 US Central (15:30 UTC)

[Robert M. <rt...@gm...>]

Tomorrow we will have our Monthly Zoom Meeting at 9:30 US Central (15:30
UTC)

Agenda:

* Q/A
* Upcoming Presentation at EUM '26
* Issue #788: Markdown Support Feedback
* Issue #804: Show command to load when using software hierarchy


Zoom Link:
https://us04web.zoom.us/j/2193049324?pwd=meA1uTMrZOWOs3dDBUbCwQrf6rAeKV.1&omn=78993258470

Re: [Lmod-users] Hooking lmod methods

[<mal...@ci...>]

Hey, 
thanks for your inputs, 
I ended up using SitePackage with a sandbox table modification as you hinted. And it works like a charm. 

The goal if this SitePackage usage is to workaround some vendor generated modules that dont play well with our site's policy (it append_path in the wrong environment variable). By hooking prepend_path through SitePackage, we avoid module modification. 

Cheers, 
Etienne 

De: "Ward Poelmans" <wpo...@gm...> 
À: "lmod-users" <lmo...@li...> 
Envoyé: Jeudi 5 Février 2026 21:07:46 
Objet: Re: [Lmod-users] Hooking lmod methods 

On Thu, Feb 5, 2026 at 8:04 PM Ward Poelmans < [ mailto:wpo...@gm... | wpo...@gm... ] > wrote: 


> I'm not sure I understand what you try to achieve but the 
> SitePackage.lua is quite reliable. We put it at 
> /etc/lmod/SitePackage.lua where it gets picked up by Lmod. We've never 
> seen issue with this, no matter how creative the users are. 

I missed the crucial bit: the file /etc/lmod/lmod_config.lua is read by Lmod. There you can tell it where to look for SitePackage.lua: 
require("strict") 
local cosmic = require("Cosmic"):singleton() 
cosmic:assign("LMOD_PACKAGE_PATH", "/etc/lmod") 

This makes Lmod look into /etc/lmod for the file SitePackage.lua 

Ward 



_______________________________________________ 
Lmod-users mailing list 
Lmo...@li... 
https://lists.sourceforge.net/lists/listinfo/lmod-users 

Re: [Lmod-users] Hooking lmod methods

[Ward P. <wpo...@gm...>]

On Thu, Feb 5, 2026 at 8:04 PM Ward Poelmans <wpo...@gm...> wrote:


> I'm not sure I understand what you try to achieve but the
> SitePackage.lua is quite reliable. We put it at
> /etc/lmod/SitePackage.lua where it gets picked up by Lmod. We've never
> seen issue with this, no matter how creative the users are.

I missed the crucial bit: the file /etc/lmod/lmod_config.lua is read by
Lmod. There you can tell it where to look for SitePackage.lua:
require("strict")
local cosmic = require("Cosmic"):singleton()
cosmic:assign("LMOD_PACKAGE_PATH", "/etc/lmod")

This makes Lmod look into /etc/lmod for the file SitePackage.lua

Ward

Re: [Lmod-users] Hooking lmod methods

[Ward P. <wpo...@gm...>]

Hi Etienne,

On Wed, Feb 4, 2026 at 10:45 AM <mal...@ci...> wrote:

> This works like a charm (so it seems), but it is easy fora user to usnet the LMOD site package env variable and so its brittle. I think I'm goingto stay with SitePackage, but is there a wait to make the solution above work ? Or an alternative way of doing this whole "shenanigans".
> I'm very much looking for advice or more conventional ways of doing that. The fact is that we have a lot of common things between our modules and wish to factorize.

I'm not sure I understand what you try to achieve but the
SitePackage.lua is quite reliable. We put it at
/etc/lmod/SitePackage.lua where it gets picked up by Lmod. We've never
seen issue with this, no matter how creative the users are.

If you want to factor out thing, use the sandbox and register it as a
custom function to use in a module file?

Ward

[Lmod-users] Hooking lmod methods

[<mal...@ci...>]

Hey, I hope this finds you well,

I'm trying to hook prepend_path & append_path so that if a given environment variable is used, I also append it into another variable.

--------
prepend_path( "LD_LIBRARY_PATH","/opt/apps/ddt/5.0.1/lib") becomes:
prepend_path( "LD_LIBRARY_PATH","/opt/apps/ddt/5.0.1/lib")
prepend_path( "MY_OTHER_VARIABLE","/opt/apps/ddt/5.0.1/lib")
--------

The code doing this hooking like like that:

--------
local function Main(context)
    local function HookPathMethods(function_name, source, target)
        local original_alter_path = context[function_name]
        local alter_path = function(...)
            local parameters = {...}
            if parameters[1] == source then
                parameters[1] = target
                original_alter_path(table.unpack(parameters))
            end
            return original_alter_path(...)
        end
        context[function_name] = alter_path
    end
    HookPathMethods("prepend_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH")
    HookPathMethods("append_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH")
end
return { Main = Main }
--------

Now, I currently have this code,  which is injected through:
--------
assert(loadfile("/path/to/hook.lua"))().Main(_ENV)
--------

This does not work when purging modules, the effect of the hooked prepend_path path remains. I then tried using the sitePackage.lua, like so:

--------
local function HookPathMethods(function_name, source, target)
    local original_function = _ENV[function_name]
    return function(...)
        local parameters = {...}
        if parameters[1] == source then
            parameters[1] = target
            original_function(table.unpack(parameters))
        end
        return original_function(...)
    end
end
sandbox_registration{
    prepend_path = HookPathMethods("prepend_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH"),
    append_path = HookPathMethods("append_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH")
}
--------

This works like a charm (so it seems), but it is easy fora user to usnet the LMOD site package env variable and so its brittle. I think I'm goingto stay with SitePackage, but is there a wait to make the solution above work ? Or an alternative way of doing this whole "shenanigans".
I'm very much looking for advice or more conventional ways of doing that. The fact is that we have a lot of common things between our modules and wish to factorize.

Have a nice day, regards,
-- 
Etienne Malaboeuf 
Ingénieur de recherche HPC, Département Calcul Intensif (DCI) 

Centre Informatique National de l'Enseignement Supérieur (CINES) 
950 rue de Saint Priest, 34097 Montpellier 
tel : (334) 67 14 14 02 
web : https://www.cines.fr | https://dci.dci-gitlab.cines.fr/webextranet

[Lmod-users] Release of Lmod 9.0.6: Support for hideRegex and forbidRegex in modulerc files

[Robert M. <rt...@gm...>]

Lmod 9.0.6 has been released.  You can now add hideRegex and forbidRegex to
specify module files using Lua-based regular expressions.  Remember that
'%' is used to quote rather than backslash.  Also that '-' (minus sign) is
a special regular expression character.

Best,
Lmod Team

Re: [Lmod-users] Lmod Zoom Mtg Jan 20th, 2026

[Matthew C. <mc...@ta...>]

Reminder that we will have an Lmod meeting tomorrow. Details below.

Best,
Lmod team



________________________________
From: Matthew Cawood <mc...@ta...>
Sent: Monday, January 12, 2026 3:13:19 PM
To: lmod-users <lmo...@li...>
Subject: [Lmod-users] Lmod Zoom Mtg Jan 20th, 2026

We will hold the next Lmod Zoom meeting  Jan. 20th at 9:30 US Central Time (15:30 UTC).

The zoom link is:

https://utexas.zoom.us/my/mcawood

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Lmod 9 updates
  *
Issue #780: Cached loads
  *
MrPackMod<https://github.com/VictorEijkhout/MrPackMod> Package installer with LMod integration
  *
User Q&A

Best,
Lmod Team

[Lmod-users] Lmod Zoom Mtg Jan 20th, 2026

[Matthew C. <mc...@ta...>]

We will hold the next Lmod Zoom meeting  Jan. 20th at 9:30 US Central Time (15:30 UTC).

The zoom link is:

https://utexas.zoom.us/my/mcawood

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Lmod 9 updates
  *
Issue #780: Cached loads
  *
MrPackMod<https://github.com/VictorEijkhout/MrPackMod> Package installer with LMod integration
  *
User Q&A

Best,
Lmod Team

Re: [Lmod-users] Query regarding Lua sandbox limitations and executing arbitrary Lua code in modulefiles.

[Matthew C. <mc...@ta...>]

Hi Zhao,

Lmod always executes modulefiles inside a restricted sandbox; there is no setting to allow full Lua execution directly in a modulefile. To run unrestricted Lua, place your logic in SitePackage.lua (which is not sandboxed) and expose selected functions to modulefiles via sandbox_registration. This is the supported way to grant modulefiles controlled access to full Lua. Modifying src/sandbox.lua to loosen restrictions is possible but unsafe and not recommended. For details, see the “SitePackage.lua and the Sandbox” section of the Lmod documentation. If you share what functionality you need, I can suggest the safest approach.

Best,
Matthew

From: Hongyi Zhao <hon...@gm...>
Date: Monday, December 1, 2025 at 19:44
To: lmod-users <lmo...@li...>
Subject: [Lmod-users] Query regarding Lua sandbox limitations and executing arbitrary Lua code in modulefiles.

Dear Robert and the Lmod community,

It appears that Lmod runs modulefiles within a restricted sandbox
environment, limiting access to the full standard Lua library (e.g.,
certain `os.*` or `io.*` functions).
Is there a configuration option or a specific method to allow the
execution of **arbitrary/full Lua code** directly within a `.lua`
modulefile?

Best regards,
Zhao
--
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province


_______________________________________________
Lmod-users mailing list
Lmo...@li...
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flmod-users&data=05%7C02%7C%7Cb9ca750255ac46f0070608de314453cd%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C639002366699830382%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LjpMAdMkyUbd6df7o054X8MTkd%2Bu93yxUd5H%2BrzFVZw%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/lmod-users>
>> This message is from an external sender. Learn more about why this <<
>> matters at https://links.utexas.edu/rtyclf.                        <<

[Lmod-users] Query regarding Lua sandbox limitations and executing arbitrary Lua code in modulefiles.

[Hongyi Z. <hon...@gm...>]

Dear Robert and the Lmod community,

It appears that Lmod runs modulefiles within a restricted sandbox
environment, limiting access to the full standard Lua library (e.g.,
certain `os.*` or `io.*` functions).
Is there a configuration option or a specific method to allow the
execution of **arbitrary/full Lua code** directly within a `.lua`
modulefile?

Best regards,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

Re: [Lmod-users] Dynamically generate a modulefile from a bash script and then load/unload it.

[Hongyi Z. <hon...@gm...>]

On Fri, Nov 21, 2025 at 7:37 PM Hongyi Zhao <hon...@gm...> wrote:
>
> Hi there,
>
> I want to dynamically generate a modulefile from a bash script and
> then load/unload it. The reason why I plan to do this is: I can
> directly modify the corresponding bash script without rewriting and
> manually generating the corresponding modulefile. See below for the
> details:
>
> The lua module file is as follows:
>
> ```
> $ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
> help([[Loads Homebrew environment]])
>
> whatis("Loads Homebrew package manager")
>
> if (mode() == "load") then
>     -- Get the directory containing this module file
>     local script_dir = myFileName():match("(.*/)")
>
>     -- Run sh_to_modulefile and capture output
>     local handle = io.popen("sh_to_modulefile --cleanEnv --from=bash
> --to=lua " .. script_dir .. "load.bash")
>     local lua_code = handle:read("*a")
>     handle:close()
>
>     -- Write to temporary file
>     local tmpfile = os.tmpname()
>     local f = io.open(tmpfile, "w")
>     f:write(lua_code)
>     f:close()
>
>     -- Execute via dofile (correct scope)
>     dofile(tmpfile)
>
>     -- Cleanup
>     os.remove(tmpfile)
> end
>
> -- Note: No unload section needed
> -- Lmod automatically reverses all setenv(), prepend_path(), and
> set_shell_function() calls
> ```
> And the bash script is as follows:
>
> ```
> $ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/load.bash
> #!/bin/bash
> # Homebrew environment initialization script
> # This script is automatically converted to Lmod module format by
> sh_to_modulefile
> # All environment variables set here will be automatically tracked and
> cleaned up on module unload
>
> brew_prefix="/home/linuxbrew/.linuxbrew"
>
> # Load Homebrew's core environment variables (PATH, HOMEBREW_PREFIX, etc.)
> eval "$($brew_prefix/bin/brew shellenv)"
>
> # Load bash completion for brew commands
> . "$brew_prefix/etc/bash_completion.d/brew"
>
> # Add Homebrew library paths for runtime linking and pkg-config
> export LD_LIBRARY_PATH="$brew_prefix/lib:${LD_LIBRARY_PATH}"
> export PKG_CONFIG_PATH="$brew_prefix/lib/pkgconfig:${PKG_CONFIG_PATH}"
>
> # Prevent automatic cleanup to preserve installed packages
> export HOMEBREW_NO_INSTALL_CLEANUP=1
> ```
>
> Then I tried to load it as follows, but failed:
>
> ```
> $ module load Homebrew/brew.git
> Lmod has detected the following error:  Unable to load module because
> of error when evaluating modulefile:
>      /home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua:
> [string "help([[Loads Homebrew environment]])..."]:15: attempt to call
> field 'tmpname' (a nil value)
>      Please check the modulefile and especially if there is a line
> number specified in the above message
> While processing the following module(s):
>     Module fullname    Module Filename
>     ---------------    ---------------
>     Homebrew/brew.git
> /home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
> ```
>
> I wonder if my above idea can be implemented based on lmod? Are there
> any hints or methods to solve this problem?

I finally figured out the following method, which solves the above problem:

```
$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
help([[Loads Homebrew environment]])
whatis("Loads Homebrew package manager")

-- 1. Define script-wide variables
-- These variables are local to this file but accessible throughout the script
local brew_prefix = "/home/linuxbrew/.linuxbrew"
local script_dir  = myFileName():match("(.*/)")
local bash_script = script_dir .. "load.bash"

-- 2. Load environment variables (PATH, MANPATH, etc.)
-- Lmod executes load.bash and captures env changes
source_sh("bash", bash_script)

-- 3. Bash completion settings
if (myShellName() == "bash") then
    local completion_file = brew_prefix .. "/etc/bash_completion.d/brew"
    -- Bash requires explicitly sourcing the completion file.
    -- The 'execute' function runs the command directly in the user's shell,
    -- bypassing Lmod's internal parsing for better performance.
    execute{cmd="source " .. completion_file, modeA={"load"}}
end

-- 4. Zsh completion settings
-- Note regarding Zsh completion:
-- Zsh users usually have 'autoload -Uz compinit && compinit' in their .zshrc.
-- If the module is loaded *after* shell startup, the completion might
not update
-- immediately because 'compinit' has already run with the old fpath.
-- However, prepending "fpath" is the standard and correct practice for modules.
if (myShellName() == "zsh") then
    -- Zsh only needs the directory added to fpath.
    -- No need to point to a specific file or use execute.
    local zsh_site_functions = brew_prefix .. "/share/zsh/site-functions"
    prepend_path("fpath", zsh_site_functions)
end

$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/load.bash
#!/bin/bash
# This script only handles Environment Variables.
# It is designed to be called by Lmod's source_sh function.

brew_prefix="/home/linuxbrew/.linuxbrew"

# 1. Let brew set core variables (PATH, MANPATH, INFOPATH, etc.)
eval "$($brew_prefix/bin/brew shellenv)"

# 2. Set additional variables
export LD_LIBRARY_PATH="$brew_prefix/lib:${LD_LIBRARY_PATH}"
export PKG_CONFIG_PATH="$brew_prefix/lib/pkgconfig:${PKG_CONFIG_PATH}"
export HOMEBREW_NO_INSTALL_CLEANUP=1
```

Regards,
Zhao

[Lmod-users] Dynamically generate a modulefile from a bash script and then load/unload it.

[Hongyi Z. <hon...@gm...>]

Hi there,

I want to dynamically generate a modulefile from a bash script and
then load/unload it. The reason why I plan to do this is: I can
directly modify the corresponding bash script without rewriting and
manually generating the corresponding modulefile. See below for the
details:

The lua module file is as follows:

```
$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
help([[Loads Homebrew environment]])

whatis("Loads Homebrew package manager")

if (mode() == "load") then
    -- Get the directory containing this module file
    local script_dir = myFileName():match("(.*/)")

    -- Run sh_to_modulefile and capture output
    local handle = io.popen("sh_to_modulefile --cleanEnv --from=bash
--to=lua " .. script_dir .. "load.bash")
    local lua_code = handle:read("*a")
    handle:close()

    -- Write to temporary file
    local tmpfile = os.tmpname()
    local f = io.open(tmpfile, "w")
    f:write(lua_code)
    f:close()

    -- Execute via dofile (correct scope)
    dofile(tmpfile)

    -- Cleanup
    os.remove(tmpfile)
end

-- Note: No unload section needed
-- Lmod automatically reverses all setenv(), prepend_path(), and
set_shell_function() calls
```
And the bash script is as follows:

```
$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/load.bash
#!/bin/bash
# Homebrew environment initialization script
# This script is automatically converted to Lmod module format by
sh_to_modulefile
# All environment variables set here will be automatically tracked and
cleaned up on module unload

brew_prefix="/home/linuxbrew/.linuxbrew"

# Load Homebrew's core environment variables (PATH, HOMEBREW_PREFIX, etc.)
eval "$($brew_prefix/bin/brew shellenv)"

# Load bash completion for brew commands
. "$brew_prefix/etc/bash_completion.d/brew"

# Add Homebrew library paths for runtime linking and pkg-config
export LD_LIBRARY_PATH="$brew_prefix/lib:${LD_LIBRARY_PATH}"
export PKG_CONFIG_PATH="$brew_prefix/lib/pkgconfig:${PKG_CONFIG_PATH}"

# Prevent automatic cleanup to preserve installed packages
export HOMEBREW_NO_INSTALL_CLEANUP=1
```

Then I tried to load it as follows, but failed:

```
$ module load Homebrew/brew.git
Lmod has detected the following error:  Unable to load module because
of error when evaluating modulefile:
     /home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua:
[string "help([[Loads Homebrew environment]])..."]:15: attempt to call
field 'tmpname' (a nil value)
     Please check the modulefile and especially if there is a line
number specified in the above message
While processing the following module(s):
    Module fullname    Module Filename
    ---------------    ---------------
    Homebrew/brew.git
/home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
```

I wonder if my above idea can be implemented based on lmod? Are there
any hints or methods to solve this problem?

Regards,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

[Lmod-users] Lmod 9.0 released

[Robert M. <rt...@gm...>]

I am happy to release the long awaited version 9.0.  This is a small change
from 8.7.67 but a big change from earlier versions.

Here is a list of the major changes since Lmod 8.0:


   1. Irreversible mode: Unloading a module can set env. vars
   2. Improved optional module tracking.
   3. More powerful hide{} and forbid{} functions to hide and forbid
   modules.
   4. The function depends_on_any() added.
   5. Collection only written to ~/.config/lmod directory.
   6. Great performance improvements when loading a module with many
   dependencies.

Enjoy this latest version of Lmod.
The Lmod Team.

Re: [Lmod-users] forbid{} issue with Lmod 8.7.65

[Robert M. <mc...@ta...>]

Currently there is no support for lua pattern match with forbid (or hide).  This might be possible. Please create an issue at github.com/TACC/Lmod which shows an example of what you are looking for.

Best,
Lmod Team

________________________________
From: Kearney, Lawrence via Lmod-users <lmo...@li...>
Sent: Tuesday, October 7, 2025 3:18 PM
To: lmo...@li... <lmo...@li...>
Cc: Barim, Deniz <DB...@au...>
Subject: [Lmod-users] forbid{} issue with Lmod 8.7.65


All,

New to the list and hopefully someone can assist. We’re running v8.7.6.5 and attempting to limit module availability by lua name pattern matching using the forbid{} function in a /etc/lmod/modulerc.lua file.



Our understanding is the “namepat” key should be available in this version but Lmod throws the following error.



“This is an unknown key: "namepat" for the forbid function”



What can we do to implement support for the “namepat” key?





-- lawrence





Lawrence Kearney

Information Technology

HPC and Research Computing Facilitator

HS 2137 | +1 706.721.5197

lke...@au...<mailto:lke...@gr...>

[Lmod-users] forbid{} issue with Lmod 8.7.65

[Kearney, L. <LKE...@au...>]

All,
New to the list and hopefully someone can assist. We're running v8.7.6.5 and attempting to limit module availability by lua name pattern matching using the forbid{} function in a /etc/lmod/modulerc.lua file.

Our understanding is the "namepat" key should be available in this version but Lmod throws the following error.

"This is an unknown key: "namepat" for the forbid function"

What can we do to implement support for the "namepat" key?


-- lawrence


Lawrence Kearney
Information Technology
HPC and Research Computing Facilitator
HS 2137 | +1 706.721.5197
lke...@au...<mailto:lke...@gr...>

Re: [Lmod-users] Tomorrow: Lmod Zoom Mtg Oct. 7th, 2025

[Robert M. <mc...@ta...>]

Cut and Paste error:  The meeting is tomorrow Oct. 7th at 9:30 Central (14:30 UTC)

Best
Lmod Team

________________________________
From: Robert McLay <mc...@ta...>
Sent: Monday, October 6, 2025 2:20 PM
To: Lmod Mailinglist <lmo...@li...>
Subject: [Lmod-users] Tomorrow: Lmod Zoom Mtg Oct. 7th, 2025

We will hold the Lmod Zoom meeting tomorrow August 5th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Q/A
  *
My Last Day at TACC is Oct. 10th
  *
This is my last meeting that I run
  *
Overview of Changes this year


Next Meeting will be in January with Matthew Cawood.  New Zoom link then.


Best,
Lmod Team

[Lmod-users] Tomorrow: Lmod Zoom Mtg Oct. 7th, 2025

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow August 5th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Q/A
  *
My Last Day at TACC is Oct. 10th
  *
This is my last meeting that I run
  *
Overview of Changes this year


Next Meeting will be in January with Matthew Cawood.  New Zoom link then.


Best,
Lmod Team

Re: [Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Loris B. <lor...@fu...>]

"Loris Bennett" <lor...@fu...> writes:

> Hi Ward,
>
> Ward Poelmans <wpo...@gm...> writes:
>
>> Hi Loris,
>>
>> What got changed is the way to do logging from Lmod. It used to call
>> the 'logger' program to emit a line to syslog. Now the hook first
>> tries the native lua interface to syslog to emit a line to
>> syslog. This should be faster as you avoid a fork.
>>
>> Did it work before with the logger command and did it break when switch to the new posix.syslog?
>
> Things broke with the transition from CentOS 7 to Alma 8.  This
> entailed a switch from Python 2 to Python 3, which caused LMODdb.py to
> fail ('raw_input' having being changed to 'input'). 
>
>> You can test it by playing with the 'if (posix.syslog) then'
>> choice. Old style is "lmod_system_execute("logger -t
>> ModuleUsageTracking -p local0.info " .. msg)".
>
> So
>
>   posix.syslog
>
> evaluates to TRUE and 
>
>  type(posix.syslog) == "table"
>
> evaluates to FALSE, so the new style is used.
>
> However, the problem is that the message is logged locally and doesn't
> get rerouted to the admin node.  So it looks like the problem is not
> with Lmod as such, but rather with the rsyslog rule set, or maybe Lmod's
> description of what the rule set should be.

Turns out I just added the forwarding rule to 'rsyslog.conf' on the
wrong machine :-(

The documentation refers to 'master' and the 'module_tracking_machine'.
However, 'master' is every machine one wants to track, so in my case it
is all the cluster nodes plus the login node.  I am collecting the
information on my cluster admin node.  Thus I find 'master' rather confusing.

@Robert: Wouldn't it be better to drop 'master' and just refer to, say,
'collector', where the log messages should end up, and 'module node',
where the 'module' command is called and creates the log message.  OK,
the latter is maybe not very good, but you get what I mean.

Sorry for the noise.

Cheers,

Loris

> Cheers,
>
> Loris
>
>> Ward
>>
>>
>> On 9/09/2025 10:45, Loris Bennett wrote:
>>> Hi,
>>> Some while ago I had module tracking working on a CentOS 7 system,
>>> such
>>> that loading of modules on the compute nodes was logged on an admin
>>> node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
>>> 8.10 cluster.  However I have encountered the following issue.
>>> On the one hand, running 'logger' directly on a compute node creates
>>> a log entry in
>>> a dedicated log file on the admin node:
>>>    Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking
>>> Some remote test message
>>> On the other hand, loading a module on the same compute node creates
>>> a
>>> log entry in '/var/log/messages' on the compute node:
>>>    Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris
>>> module=Emacs/28.2-GCCcore-12.2.0
>>> path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua
>>> host=c001.curta.zedat.fu-berlin.de time=1757406848.886437
>>> The ruleset for rsyslog is as follows:
>>>    $Ruleset remote
>>>    if $programname contains 'ModuleUsageTracking' then @dadmin
>>>    $Ruleset RSYSLOG_DefaultRuleset
>>>    # provides UDP syslog reception
>>>    $ModLoad imudp
>>>    $InputUDPServerBindRuleset remote
>>>    $UDPServerRun 514
>>> Why might the ruleset not be being applied to the message generated
>>> by
>>> SitePackage.lua?
>>> Note that SitePackage.lua is taken from
>>>    https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html
>>> which seems to be for Lmod 8.7.64, but I had to add
>>>    local posix   = require("posix")
>>> to the top of the file to prevent an error about 'posix' being an
>>> unknown variable, so maybe the issue is related to some difference
>>> between 8.7.55 and 8.7.64.
>>> Any insights would be greatly appreciated.
>>> Cheers,
>>> Loris
>>> 
>>
>>
>>
>> _______________________________________________
>> Lmod-users mailing list
>> Lmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/lmod-users
>>
-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin

Re: [Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Loris B. <lor...@fu...>]

Hi Ward,

Ward Poelmans <wpo...@gm...> writes:

> Hi Loris,
>
> What got changed is the way to do logging from Lmod. It used to call
> the 'logger' program to emit a line to syslog. Now the hook first
> tries the native lua interface to syslog to emit a line to
> syslog. This should be faster as you avoid a fork.
>
> Did it work before with the logger command and did it break when switch to the new posix.syslog?

Things broke with the transition from CentOS 7 to Alma 8.  This
entailed a switch from Python 2 to Python 3, which caused LMODdb.py to
fail ('raw_input' having being changed to 'input'). 

> You can test it by playing with the 'if (posix.syslog) then'
> choice. Old style is "lmod_system_execute("logger -t
> ModuleUsageTracking -p local0.info " .. msg)".

So

  posix.syslog

evaluates to TRUE and 

 type(posix.syslog) == "table"

evaluates to FALSE, so the new style is used.

However, the problem is that the message is logged locally and doesn't
get rerouted to the admin node.  So it looks like the problem is not
with Lmod as such, but rather with the rsyslog rule set, or maybe Lmod's
description of what the rule set should be.

Cheers,

Loris

> Ward
>
>
> On 9/09/2025 10:45, Loris Bennett wrote:
>> Hi,
>> Some while ago I had module tracking working on a CentOS 7 system,
>> such
>> that loading of modules on the compute nodes was logged on an admin
>> node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
>> 8.10 cluster.  However I have encountered the following issue.
>> On the one hand, running 'logger' directly on a compute node creates
>> a log entry in
>> a dedicated log file on the admin node:
>>    Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking
>> Some remote test message
>> On the other hand, loading a module on the same compute node creates
>> a
>> log entry in '/var/log/messages' on the compute node:
>>    Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris
>> module=Emacs/28.2-GCCcore-12.2.0
>> path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua
>> host=c001.curta.zedat.fu-berlin.de time=1757406848.886437
>> The ruleset for rsyslog is as follows:
>>    $Ruleset remote
>>    if $programname contains 'ModuleUsageTracking' then @dadmin
>>    $Ruleset RSYSLOG_DefaultRuleset
>>    # provides UDP syslog reception
>>    $ModLoad imudp
>>    $InputUDPServerBindRuleset remote
>>    $UDPServerRun 514
>> Why might the ruleset not be being applied to the message generated
>> by
>> SitePackage.lua?
>> Note that SitePackage.lua is taken from
>>    https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html
>> which seems to be for Lmod 8.7.64, but I had to add
>>    local posix   = require("posix")
>> to the top of the file to prevent an error about 'posix' being an
>> unknown variable, so maybe the issue is related to some difference
>> between 8.7.55 and 8.7.64.
>> Any insights would be greatly appreciated.
>> Cheers,
>> Loris
>> 
>
>
>
> _______________________________________________
> Lmod-users mailing list
> Lmo...@li...
> https://lists.sourceforge.net/lists/listinfo/lmod-users
>
-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin

Re: [Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Ward P. <wpo...@gm...>]

Hi Loris,

What got changed is the way to do logging from Lmod. It used to call the 'logger' program to emit a line to syslog. Now the hook first tries the native lua interface to syslog to emit a line to syslog. This should be faster as you avoid a fork.

Did it work before with the logger command and did it break when switch to the new posix.syslog?
You can test it by playing with the 'if (posix.syslog) then' choice. Old style is "lmod_system_execute("logger -t ModuleUsageTracking -p local0.info " .. msg)".


Ward


On 9/09/2025 10:45, Loris Bennett wrote:
> Hi,
> 
> Some while ago I had module tracking working on a CentOS 7 system, such
> that loading of modules on the compute nodes was logged on an admin
> node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
> 8.10 cluster.  However I have encountered the following issue.
> 
> On the one hand, running 'logger' directly on a compute node creates a log entry in
> a dedicated log file on the admin node:
> 
>    Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking Some remote test message
> 
> On the other hand, loading a module on the same compute node creates a
> log entry in '/var/log/messages' on the compute node:
> 
>    Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris module=Emacs/28.2-GCCcore-12.2.0 path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua host=c001.curta.zedat.fu-berlin.de time=1757406848.886437
> 
> The ruleset for rsyslog is as follows:
> 
>    $Ruleset remote
>    if $programname contains 'ModuleUsageTracking' then @dadmin
>    $Ruleset RSYSLOG_DefaultRuleset
> 
>    # provides UDP syslog reception
>    $ModLoad imudp
>    $InputUDPServerBindRuleset remote
>    $UDPServerRun 514
> 
> Why might the ruleset not be being applied to the message generated by
> SitePackage.lua?
> 
> Note that SitePackage.lua is taken from
> 
>    https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html
> 
> which seems to be for Lmod 8.7.64, but I had to add
> 
>    local posix   = require("posix")
> 
> to the top of the file to prevent an error about 'posix' being an
> unknown variable, so maybe the issue is related to some difference
> between 8.7.55 and 8.7.64.
> 
> Any insights would be greatly appreciated.
> 
> Cheers,
> 
> Loris
> 

[Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Loris B. <lor...@fu...>]

Hi,

Some while ago I had module tracking working on a CentOS 7 system, such
that loading of modules on the compute nodes was logged on an admin
node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
8.10 cluster.  However I have encountered the following issue.

On the one hand, running 'logger' directly on a compute node creates a log entry in
a dedicated log file on the admin node:

  Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking Some remote test message

On the other hand, loading a module on the same compute node creates a
log entry in '/var/log/messages' on the compute node:

  Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris module=Emacs/28.2-GCCcore-12.2.0 path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua host=c001.curta.zedat.fu-berlin.de time=1757406848.886437

The ruleset for rsyslog is as follows: 

  $Ruleset remote
  if $programname contains 'ModuleUsageTracking' then @dadmin
  $Ruleset RSYSLOG_DefaultRuleset

  # provides UDP syslog reception
  $ModLoad imudp
  $InputUDPServerBindRuleset remote
  $UDPServerRun 514

Why might the ruleset not be being applied to the message generated by
SitePackage.lua?

Note that SitePackage.lua is taken from 

  https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html

which seems to be for Lmod 8.7.64, but I had to add

  local posix   = require("posix")

to the top of the file to prevent an error about 'posix' being an
unknown variable, so maybe the issue is related to some difference
between 8.7.55 and 8.7.64.

Any insights would be greatly appreciated.

Cheers,

Loris

-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin

[Lmod-users] Tomorrow: Lmod Zoom Mtg Sept. 9th, at 9:30 US Central (14:30 UTC)

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow Sept. 9th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Lmod 9.0 coming next week
  *
Issue #789: Hierarchical bug
  *
Issue #788: Support for markdown in help and whatis

Best,
Lmod Team