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

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

[Lmod-users] Lmod Zoom mtg sept 9th not sept 2nd

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

See you next week

Best,
Lmod Team

Re: [Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

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

What you are seeing is a bug but one that we can't reproduce:

% ml -v

Modules based on Lua: Version 8.7.65 2025-08-05 10:24 -06:00
    by Robert McLay mc...@ta...

% ml use ~/t/MF
% ml intel/oneapi_2022.3.1-sw1088
% ml list intel

Currently Loaded Modules Matching: intel
  1) intel/oneapi_2022.3.1-sw1088

There must be something special about your setup.

Please create an issue at https://github.com/TACC/Lmod.

The quickest way to get a bug fixed is to use the bug reporting shell script provided.  We can only fix bugs that we can reproduce with the latest version of Lmod.

Best,
Lmod Team


________________________________
From: Ryan Novosielski via Lmod-users <lmo...@li...>
Sent: Thursday, August 21, 2025 12:20 PM
To: Lmod-users <lmo...@li...>
Subject: Re: [Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

We rolled back production and the old version is working normally and the new one is still doing this under the pre-install state, so we can do any troubleshooting we need to do if anyone has any ideas.

On Aug 19, 2025, at 16:34, Ryan Novosielski via Lmod-users <lmo...@li...> wrote:

Hi all,

Having something I’ve not seen before after upgrading from 8.7.32 to 8.7.65.

For especially compilers that are in a non-default module location (eg. you use “module use” to activate it), I’m getting this message, for example:

[novosirj@amarel1 ~]$ module load intel/oneapi_2022.3.1-sw1088
Lmod has detected the following error:  These module(s) or extension(s) exist but cannot be loaded as requested:
"intel/oneapi_2022.3.1-sw1088"
   Try: "module spider intel/oneapi_2022.3.1-sw1088" to see how to load the module(s).

However I do not see a reason:

[novosirj@amarel1 ~]$ module spider intel/oneapi_2022.3.1-sw1088

------------------------------------------------------------------------------------------------------------------------------------------
  intel/oneapi_2022.3.1-sw1088: intel/oneapi_2022.3.1-sw1088
------------------------------------------------------------------------------------------------------------------------------------------
    Description:
      Intel oneAPI compiler


    This module can be loaded directly: module load intel/oneapi_2022.3.1-sw1088

    Help:
      This module loads the intel oneAPI compiler.

Did I miss something in the release notes? I’m still hunting around for a difference. These are user-generated module files, vs. our sysadmin-generated, but… they appear the same otherwise.

--
#BlackLivesMatter
____
|| \\UTGERS,     |---------------------------*O*---------------------------
||_// the State  |     Ryan Novosielski (he/him) - nov...@ru...
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB A555B, Newark
     `'

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

Re: [Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

[Ryan N. <nov...@ru...>]

We rolled back production and the old version is working normally and the new one is still doing this under the pre-install state, so we can do any troubleshooting we need to do if anyone has any ideas.

On Aug 19, 2025, at 16:34, Ryan Novosielski via Lmod-users <lmo...@li...> wrote:

Hi all,

Having something I’ve not seen before after upgrading from 8.7.32 to 8.7.65.

For especially compilers that are in a non-default module location (eg. you use “module use” to activate it), I’m getting this message, for example:

[novosirj@amarel1 ~]$ module load intel/oneapi_2022.3.1-sw1088
Lmod has detected the following error:  These module(s) or extension(s) exist but cannot be loaded as requested:
"intel/oneapi_2022.3.1-sw1088"
   Try: "module spider intel/oneapi_2022.3.1-sw1088" to see how to load the module(s).

However I do not see a reason:

[novosirj@amarel1 ~]$ module spider intel/oneapi_2022.3.1-sw1088

------------------------------------------------------------------------------------------------------------------------------------------
  intel/oneapi_2022.3.1-sw1088: intel/oneapi_2022.3.1-sw1088
------------------------------------------------------------------------------------------------------------------------------------------
    Description:
      Intel oneAPI compiler


    This module can be loaded directly: module load intel/oneapi_2022.3.1-sw1088

    Help:
      This module loads the intel oneAPI compiler.

Did I miss something in the release notes? I’m still hunting around for a difference. These are user-generated module files, vs. our sysadmin-generated, but… they appear the same otherwise.

--
#BlackLivesMatter
____
|| \\UTGERS,     |---------------------------*O*---------------------------
||_// the State  |     Ryan Novosielski (he/him) - nov...@ru...
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB A555B, Newark
     `'

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

[Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

[Ryan N. <nov...@ru...>]

Hi all,

Having something I’ve not seen before after upgrading from 8.7.32 to 8.7.65.

For especially compilers that are in a non-default module location (eg. you use “module use” to activate it), I’m getting this message, for example:

[novosirj@amarel1 ~]$ module load intel/oneapi_2022.3.1-sw1088
Lmod has detected the following error:  These module(s) or extension(s) exist but cannot be loaded as requested:
"intel/oneapi_2022.3.1-sw1088"
   Try: "module spider intel/oneapi_2022.3.1-sw1088" to see how to load the module(s).

However I do not see a reason:

[novosirj@amarel1 ~]$ module spider intel/oneapi_2022.3.1-sw1088

------------------------------------------------------------------------------------------------------------------------------------------
  intel/oneapi_2022.3.1-sw1088: intel/oneapi_2022.3.1-sw1088
------------------------------------------------------------------------------------------------------------------------------------------
    Description:
      Intel oneAPI compiler


    This module can be loaded directly: module load intel/oneapi_2022.3.1-sw1088

    Help:
      This module loads the intel oneAPI compiler.

Did I miss something in the release notes? I’m still hunting around for a difference. These are user-generated module files, vs. our sysadmin-generated, but… they appear the same otherwise.

--
#BlackLivesMatter
____
|| \\UTGERS,     |---------------------------*O*---------------------------
||_// the State  |     Ryan Novosielski (he/him) - nov...@ru...
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB A555B, Newark
     `'

[Lmod-users] Tomorrow: Lmod Zoom Mtg August 5th at 9:30 US Central (14:30 UTC)

[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:


  *
Big Cache update
  *
Issue #780: Not rebuilding cache every time causes a problem with cached loads: Still working on this
  *
Nushell support
  *
Issue #778: Solved problem with N/V/V layout

Next Meeting Sept. 9th.

Best,
Lmod Team

[Lmod-users] Tomorrow: Lmod Zoom Mtg: July 1th at 9:30 US Central (14:30 UTC)

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

We will hold the Lmod Zoom meeting tomorrow July 1th 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
  *
Release of Lmod 8.7.63
  *
Big improvements in speed
  *
Results of Big Cache tests
  *
Lmod internal Code and overview released.
  *
Is Big Cache worth it?
  *
Issue #773: Adding more information to spider cache?

Best,
Lmod Team


  *

Re: [Lmod-users] lmod with different CPUs

[Grigory S. <gri...@um...>]

Hi Wadud,


Of the approaches, there seems to be at least two: 1) to have an “arch” module somewhere in a single hierarchy that acts like a parent (arch/avx2, arch/avx512, arch/sse); so that users  (and software builders) would be able to choose the CPU architecture.
Or 2) to have completely separate module hierarchies for each CPUs that would switch automatically based on the node’s hardware.

--
Grigory Shamov
Site Lead / HPC Specialist
University of Manitoba and DRI Alliance Canada


From: Wadud Miah via Lmod-users <lmo...@li...>
Reply-To: Wadud Miah <wad...@ku...>
Date: Tuesday, June 17, 2025 at 5:07 AM
To: "lmo...@li..." <lmo...@li...>
Subject: [Lmod-users] lmod with different CPUs

Caution! This message was sent from outside the University of Manitoba.

Hi,

We have AMD and Intel CPUs in our cluster and wanted some generic advice on how to organise lmod with applications built on different CPUs. Any advice will be appreciated.

Regards,




Dr. Wadud Miah
Scientific Computing Support Senior Specialist
Scientific Computing Support





[cid:image001.png@01DBDF64.5E676680]



    wad...@ku...
    T : +971 2 312 5531
    ku.ac.ae<http://www.ku.ac.ae/>

PO. Box 127788, Abu Dhabi, UAE
Khalifa University
[cid:image002.png@01DBDF64.5E676680]<http://www.ku.ac.ae/social>



"Disclaimer: This email and any attachments are intended solely for the use of the recipient(s) and may contain confidential or legally privileged information. If you are not the intended recipient, please notify the sender immediately and delete this email. Any unauthorized review, use, or distribution is prohibited. The views expressed in this email are those of the sender and may not reflect the official policies or position of Khalifa University of Science and Technology."

[Lmod-users] lmod with different CPUs

[Wadud M. <wad...@ku...>]

Hi,

We have AMD and Intel CPUs in our cluster and wanted some generic advice on how to organise lmod with applications built on different CPUs. Any advice will be appreciated.

Regards,




Dr. Wadud Miah
Scientific Computing Support Senior Specialist
Scientific Computing Support





[cid:image001.png@01DBDF84.10839EA0]



    wad...@ku...
    T : +971 2 312 5531
    ku.ac.ae<http://www.ku.ac.ae/>

PO. Box 127788, Abu Dhabi, UAE
Khalifa University
[cid:image002.png@01DBDF84.10839EA0]<http://www.ku.ac.ae/social>



"Disclaimer: This email and any attachments are intended solely for the use of the recipient(s) and may contain confidential or legally privileged information. If you are not the intended recipient, please notify the sender immediately and delete this email. Any unauthorized review, use, or distribution is prohibited. The views expressed in this email are those of the sender and may not reflect the official policies or position of Khalifa University of Science and Technology."

[Lmod-users] Tomorrow: Lmod Zoom Mtg: June 3th at 9:30 US Central (14:30 UTC)

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

We will hold the Lmod Zoom meeting tomorrow June 3th 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
  *
Progress on: generating spider cache files that contain the contents of each module file
  *
Is this going to improve performance on parallel file systems?
  *
LMOD_DYNAMIC_SPIDER_CACHE changes coming in 8.8
  *
Bug fixes:
     *
#764: source_sh() and LD_LIBRARY_PATH
     *
#761, #766: unreadable .modulerc* and other modulefiles
     *
#759: Aliases with "-" not being found

Best,
Lmod Team

Re: [Lmod-users] Best practice for managing multiple module versions with shared configuration?

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

On Thu, May 22, 2025 at 3:15 PM Hongyi Zhao <hon...@gm...> wrote:
>
> Hi,
>
> I have multiple VASP module versions (6.4.3, 6.5.0 and 6.5.1 in my
> case, as shown below) that share identical configurations. Currently
> using this approach:
>
> ```
> werner@x13dai-t:~/Public/repo/github.com/TACC/modulefiles/applications/vasp$
> ls -la |grep VASP.6.X.X
> lrwxrwxrwx  1 werner werner   27 May 22 14:58 6.4.3-oneapi.2024.2.0 ->
> .VASP.6.X.X-oneapi.2024.2.0
> lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.0-oneapi.2024.2.0 ->
> .VASP.6.X.X-oneapi.2024.2.0
> lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.1-oneapi.2024.2.0 ->
> .VASP.6.X.X-oneapi.2024.2.0
> -rw-rw-r--  1 werner werner 1845 May 22 14:54 .VASP.6.X.X-oneapi.2024.2.0
> ```
>
> All versions symlink to a hidden base file (dot-prefixed, doesn't show
> in `module avail`).
>
> My Questions are as follows:
> 1. Is this a recommended approach for managing shared configurations?
> 2. Are there better alternatives methods than the one used above by me?
> 3. Any potential issues with the symlink approach?
>
> Thanks for any insights.

Thanks everyone for any insights on this topic!

After diving deeper into Lmod's source code and testing the hidden
module functionality, I can now answer my own questions:

1. Is this approach recommended?
Yes! The symlink-to-hidden-modulefile pattern is actually well-aligned
with Lmod's design. The dot-prefix hiding is a core feature
implemented in Lmod's module discovery logic, not a hack.

2. Are there better alternatives?
For my use case (3 similar VASP versions), I explored alternatives but
they add complexity without significant benefits:

- Lua function approach: Create a shared Lua module with common
functions, then `require()` it in each modulefile. This needs proper
Lua module paths and is overkill for simple configuration sharing.

- Include/loadfile patterns: Use
`loadfile("/path/to/shared-config.lua")()` in each modulefile to
source common code. This creates additional file dependencies and path
management overhead.

- ModuleRC hierarchies: Use `.modulerc.lua` with `family()` or complex
inheritance. This is designed more for compiler/MPI toolchain
hierarchies than simple config sharing.

My current symlink approach hits the sweet spot of simplicity and
maintainability without the overhead.

3. Any potential issues?
Testing shows it works reliably:
```bash
$ module avail                        # Clean output, hidden file doesn't show
$ module --show_hidden avail          # Shows .VASP.6.X.X... (H) when needed
$ module load vasp/6.4.3-oneapi.2024.2.0  # Loads correctly via symlink
```

I'll stick with my current approach. Sometimes the straightforward
solution is the right one!

Thanks for this great community resource.

Best,
Zhao

>
> 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] Best practice for managing multiple module versions with shared configuration?

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

Hi,

I have multiple VASP module versions (6.4.3, 6.5.0 and 6.5.1 in my
case, as shown below) that share identical configurations. Currently
using this approach:

```
werner@x13dai-t:~/Public/repo/github.com/TACC/modulefiles/applications/vasp$
ls -la |grep VASP.6.X.X
lrwxrwxrwx  1 werner werner   27 May 22 14:58 6.4.3-oneapi.2024.2.0 ->
.VASP.6.X.X-oneapi.2024.2.0
lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.0-oneapi.2024.2.0 ->
.VASP.6.X.X-oneapi.2024.2.0
lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.1-oneapi.2024.2.0 ->
.VASP.6.X.X-oneapi.2024.2.0
-rw-rw-r--  1 werner werner 1845 May 22 14:54 .VASP.6.X.X-oneapi.2024.2.0
```

All versions symlink to a hidden base file (dot-prefixed, doesn't show
in `module avail`).

My Questions are as follows:
1. Is this a recommended approach for managing shared configurations?
2. Are there better alternatives methods than the one used above by me?
3. Any potential issues with the symlink approach?

Thanks for any insights.

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] Separate labels for metamodules and subdirectories

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

Hi Ron,

You are correct that categories apply to directories, not to files. To get different categories in the example, move genomics.lua to its own directory and assign a different category to that directory.
Let me know if you have any questions.

Best,
Matthew

From: Rahaman, Ronald O <rra...@ga...>
Date: Wednesday, May 14, 2025 at 18:15
To: Lmo...@li... <Lmo...@li...>
Subject: [Lmod-users] Separate labels for metamodules and subdirectories
We'd like to show some meta-modules in a named category.  Furthermore, we'd like the meta-modules' category to be different that their sibling directories' category.  How can we do that?

For example, using the example in the docs (https://lmod.readthedocs.io/en/latest/055_module_names.html#module-naming-scheme-category-name-version-c-n-v), we'd like to:

  *   Have the meta-module "genomics" appear in Category A

  *   Have "bowtie" and "tophat" appear in Category B

My attempts are failing, and I think it's because categories can be applied to a directory but not a lua file (https://lmod.readthedocs.io/en/latest/200_avail_custom.html#providing-custom-labels-for-avail).  Let me know if I'm mistaken.

Thanks,
Ron

--------

Ron Rahaman
Research Scientist II, Research Software Engineer
Partnership for an Advanced Computing Environment (PACE)
Open Source Programming Office (OSPO)
Georgia Institute of Technology

[Lmod-users] Separate labels for metamodules and subdirectories

[Rahaman, R. O <rra...@ga...>]

We'd like to show some meta-modules in a named category.  Furthermore, we'd like the meta-modules' category to be different that their sibling directories' category.  How can we do that?

For example, using the example in the docs (https://lmod.readthedocs.io/en/latest/055_module_names.html#module-naming-scheme-category-name-version-c-n-v), we'd like to:

  *
Have the meta-module "genomics" appear in Category A
  *
Have "bowtie" and "tophat" appear in Category B

My attempts are failing, and I think it's because categories can be applied to a directory but not a lua file (https://lmod.readthedocs.io/en/latest/200_avail_custom.html#providing-custom-labels-for-avail).  Let me know if I'm mistaken.

Thanks,
Ron

--------

Ron Rahaman
Research Scientist II, Research Software Engineer
Partnership for an Advanced Computing Environment (PACE)
Open Source Programming Office (OSPO)
Georgia Institute of Technology