Linux load module file

Как загружать и выгружать модули ядра в Linux

Оригинал: How to Load and Unload Kernel Modules in Linux
Автор: Aaron Kili
Дата публикации: 13 июня 2017 года
Перевод: А. Кривошей
Дата перевода: июль 2017 г.

Модуль ядра — это программа, которая может быть загружена в ядро операционной системы, или выгружена из него по запросу без перекомпиляции ядра или перезагрузки системы. Модули предназначены для расширения функциональности ядра. Другими словами можно сказать, что модули похожи на плагины к программам, например к WordPress. Плагины расширяют функциональность программы без включения их в исходный код.

Аналогично, без модулей ядро должно быть собрано с включением всей необходимой функциональности непосредственно в образ ядра. Это приводит к увеличению его размеров, кроме того, для добавления любой новой функциональности системным администраторам необходимо перекомпилировать ядро.

Простой пример модуля — драйвер, который предоставляет ядру доступ к аппаратному устройству, подключенному к компьютеру.

Список всех загруженных модулей ядра в Linux

В Linux названия всех модулей заканчиваются расширением .ko, и обычно они загружаются автоматически при обнаружении оборудования во время загрузки системы. Однако системный администратор может управлять модулями с помощью специальных команд.

Для вывода списка всех загруженных модулей в Linux может использоваться команда lsmod (list modules), которая читает содержимое /proc/modules.

Как загрузить или выгрузить (удалить) модули ядра в Linux

Для загрузки модуля ядра мы можем использовать команду insmod (insert module). Здесь необходимо задать полный путь к модулю. Приведенная ниже команда загружает модуль speedstep-lib.ko.

Для выгрузки модуля ядра мы будем использовать команду rmmod (remove module). Следующая команда выгрузит модуль speedstep-lib.ko.

Управление модулями ядра с помощью команды modprobe

modprobe — это интеллектуальная команда для чтения списка, загрузки и выгрузки модулей ядра. Она производит поиск всех модулей и соответствующих файлов в директории /lib/modules/$(uname -r), но не включает в поиск альтернативные конфигурационные файлы в директории /etc/modprobe.d. Таким образом, здесь вам не нужно вводить полный путь к модулю — в этом преимущество modprobe по сравнению с ранее описанными командами.

Для загрузки модуля просто введите его имя.

Для выгрузки модуля используется флаг -r.

Замечание: в modprobe выполняется автоматическое преобразование подчеркивания, поэтому при вводе названий модулей нет никакой разницы между _ и -.

Более подробно ознакомиться с опциями можно на man-странице modprobe.

Источник

How to Load and Unload Kernel Modules in Linux

A kernel module is a program which can loaded into or unloaded from the kernel upon demand, without necessarily recompiling it (the kernel) or rebooting the system, and is intended to enhance the functionality of the kernel.

In general software terms, modules are more or less like plugins to a software such as WordPress. Plugins provide means to extend software functionality, without them, developers would have to build a single massive software with all functionalities integrated in a package. If new functionalities are needed, they would have to be added in new versions of a software.

Likewise without modules, the kernel would have to be built with all functionalities integrated directly into the kernel image. This would mean having bigger kernels, and system administrators would need to recompile the kernel every time a new functionality is needed.

A simple example of a module is a device driver – which enables the kernel to access a hardware component/device connected to the system.

List All Loaded Kernel Modules in Linux

In Linux, all modules end with the .ko extension, and they are normally loaded automatically as the hardware is detected at system boot. However a system administrator can manage the modules using certain commands.

To list all currently loaded modules in Linux, we can use the lsmod (list modules) command which reads the contents of /proc/modules like this.

How to Load and Unload (Remove) Kernel Modules in Linux

To load a kernel module, we can use the insmod (insert module) command. Here, we have to specify the full path of the module. The command below will insert the speedstep-lib.ko module.

To unload a kernel module, we use the rmmod (remove module) command. The following example will unload or remove the speedstep-lib.ko module.

How to Manage Kernel Modules Using modprobe Command

modprobe is an intelligent command for listing, inserting as well as removing modules from the kernel. It searches in the module directory /lib/modules/$(uname -r) for all the modules and related files, but excludes alternative configuration files in the /etc/modprobe.d directory.

Here, you don’t need the absolute path of a module; this is the advantage of using modprobe over the previous commands.

To insert a module, simply provide its name as follows.

To remove a module, use the -r flag like this.

Note: Under modprobe, automatic underscore conversion is performed, so there is no difference between _ and – while entering module names.

For more usage info and options, read through the modprobe man page.

Do not forget to check out:

That’s all for now! Do you have any useful ideas, that you wanted us to add to this guide or queries, use the feedback form below to drop them to us.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

Kernel module

Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system.

To create a kernel module, you can read The Linux Kernel Module Programming Guide. A module can be configured as built-in or loadable. To dynamically load or remove a module, it has to be configured as a loadable module in the kernel configuration (the line related to the module will therefore display the letter M ).

Contents

Obtaining information

Modules are stored in /usr/lib/modules/kernel_release . You can use the command uname -r to get your current kernel release version.

To show what kernel modules are currently loaded:

To show information about a module:

To list the options that are set for a loaded module:

To display the comprehensive configuration of all the modules:

To display the configuration of a particular module:

List the dependencies of a module (or alias), including the module itself:

Automatic module loading with systemd

Today, all necessary modules loading is handled automatically by udev, so if you do not need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any configuration file. However, there are cases where you might want to load an extra module during the boot process, or blacklist another one for your computer to function properly.

Kernel modules can be explicitly listed in files under /etc/modules-load.d/ for systemd to load them during boot. Each configuration file is named in the style of /etc/modules-load.d/program.conf . Configuration files simply contain a list of kernel modules names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored.

See modules-load.d(5) for more details.

Manual module handling

Kernel modules are handled by tools provided by kmod package. You can use these tools manually.

To load a module:

To load a module by filename (i.e. one that is not installed in /usr/lib/modules/$(uname -r)/ ):

To unload a module:

Setting module options

To pass a parameter to a kernel module, you can pass them manually with modprobe or assure certain parameters are always applied using a modprobe configuration file or by using the kernel command line.

Manually at load time using modprobe

The basic way to pass parameters to a module is using the modprobe command. Parameters are specified on command line using simple key=value assignments:

Using files in /etc/modprobe.d/

Files in /etc/modprobe.d/ directory can be used to pass module settings to udev, which will use modprobe to manage the loading of the modules during system boot. Configuration files in this directory can have any name, given that they end with the .conf extension. The syntax is:

Using kernel command line

If the module is built into the kernel, you can also pass options to the module using the kernel command line. For all common bootloaders, the following syntax is correct:

Simply add this to your bootloader’s kernel-line, as described in Kernel Parameters.

Aliasing

Aliases are alternate names for a module. For example: alias my-mod really_long_modulename means you can use modprobe my-mod instead of modprobe really_long_modulename . You can also use shell-style wildcards, so alias my-mod* really_long_modulename means that modprobe my-mod-something has the same effect. Create an alias:

Some modules have aliases which are used to automatically load them when they are needed by an application. Disabling these aliases can prevent automatic loading but will still allow the modules to be manually loaded.

Blacklisting

Blacklisting, in the context of kernel modules, is a mechanism to prevent the kernel module from loading. This could be useful if, for example, the associated hardware is not needed, or if loading that module causes problems: for instance there may be two kernel modules that try to control the same piece of hardware, and loading them together would result in a conflict.

Some modules are loaded as part of the initramfs. mkinitcpio -M will print out all automatically detected modules: to prevent the initramfs from loading some of those modules, blacklist them in a .conf file under /etc/modprobe.d and it shall be added in by the modconf hook during image generation. Running mkinitcpio -v will list all modules pulled in by the various hooks (e.g. filesystems hook, block hook, etc.). Remember to add that .conf file to the FILES array in /etc/mkinitcpio.conf if you do not have the modconf hook in your HOOKS array (e.g. you have deviated from the default configuration), and once you have blacklisted the modules regenerate the initramfs, and reboot afterwards.

Using files in /etc/modprobe.d/

Create a .conf file inside /etc/modprobe.d/ and append a line for each module you want to blacklist, using the blacklist keyword. If for example you want to prevent the pcspkr module from loading:

However, there is a workaround for this behaviour; the install command instructs modprobe to run a custom command instead of inserting the module in the kernel as normal, so you can force the module to always fail loading with:

This will effectively blacklist that module and any other that depends on it.

Using kernel command line

You can also blacklist modules from the bootloader.

Simply add module_blacklist=modname1,modname2,modname3 to your bootloader’s kernel line, as described in Kernel parameters.

Troubleshooting

Modules do not load

In case a specific module does not load and the boot log (accessible by running journalctl -b as root) says that the module is blacklisted, but the directory /etc/modprobe.d/ does not show a corresponding entry, check another modprobe source folder at /usr/lib/modprobe.d/ for blacklisting entries.

A module will not be loaded if the «vermagic» string contained within the kernel module does not match the value of the currently running kernel. If it is known that the module is compatible with the current running kernel the «vermagic» check can be ignored with modprobe —force-vermagic .

Источник

Installing Modules on Unix¶

This document is an overview of building and installing Modules on a Unix system.

Requirements¶

Modules consists of one Tcl script so to run it from a user shell the only requirement is to have a working version of tclsh (version 8.5 or later) available on your system. tclsh is a part of Tcl (http://www.tcl.tk/software/tcltk/).

To install Modules from a distribution tarball or a clone of the git repository, a build step is there to tailor the modulecmd.tcl and the initialization scripts to the chosen installation configuration and create the documentation files. This build step requires the tools to be found on your system:

When also installing Modules Tcl extension library (enabled by default), these additional tools are needed:

When installing from a distribution tarball, documentation is pre-built and scripts to configure Modules Tcl extension library build are already generated. Thus no additional software is required. When installing from a clone of the git repository or from a git archive export, documentation and scripts to prepare for compilation have to be built and the following tools are required:

Get Modules¶

Modules can usually be installed with the package manager of your Unix system. It it is available by default on most Linux distributions, on OS X and FreeBSD either under the name of modules or environment-modules .

If you want to install Modules from sources, tarballs from all Modules’ releases can be retrieved from one of the following link:

For instance to download then unpack the last release of Modules:

Installation instructions¶

The simplest way to build and install Modules is:

Some explanation, step by step:

1. cd to the directory containing the package’s source code. Your system must have the above requirements installed to properly build scripts, and documentation if build occurs from a clone of the git repository.
2. Type ./configure to adapt the installation for your system. At this step you can choose the installation paths and the features you want to enable in the initialization scripts (see Build and installation options section below for a complete overview of the available options)
3. Type make to adapt scripts to the configuration, build Tcl extension library if enabled and build documentation if working from git repository.
4. Optionally, type make test to run the test suite.
5. Type make install to install modulecmd.tcl, initialization scripts and documentation.
6. Optionally, type make testinstall to run the installation test suite.
7. You can remove the built files from the source code directory by typing make clean . To also remove the files that configure created, type make distclean .

A default installation process like described above will install Modules under /usr/local/Modules . You can change this with the —prefix option. By default, /usr/local/Modules/modulefiles will be setup as the default directory containing modulefiles. —modulefilesdir option enables to change this directory location. For example:

See Build and installation options section to discover all ./configure option available.

GNU Make is excepted to be used for this build and installation process. On non-Linux systems, the gmake should be called instead of make .

Configuration¶

Once installed you should review and adapt the configuration to make it fit your needs. The following steps are provided for example. They are not necessarily mandatory as it depends of the kind of setup you want to achieve.

Enable Modules initialization at shell startup. An easy way to get module function defined and its associated configuration setup at shell startup is to make the initialization scripts part of the system-wide environment setup in /etc/profile.d . To do so, make a link in this directory to the profile scripts that can be found in your Modules installation init directory:

These profile scripts will automatically adapt to the kind of sh or csh shell you are running.

Another approach may be to get the Modules initialization script sourced from the shell configuration startup file. For instance following line could be added to the end of the

/.bashrc file if running Bash shell:

Beware that shells have multiple ways to initialize depending if they are a login shell or not and if they are launched in interactive mode or not.

Define module paths to enable by default. Edit initrc configuration file in the directory designated by the —etcdir option or edit modulespath in the same directory.

If you use modulespath configuration file, add one line mentioning each modulefile directory:

If you use initrc configuration file, add one line mentioning each modulefile directory prefixed by the module use command:

In case both configuration files initrc and modulespath are present, Modules initialization process will first evaluate modulespath then initrc .

By default, the modulepaths specified on the —with-modulepath installation option are automatically defined for use in initrc (or in modulespath if the —enable-modulespath installation option has been set).

If you have set —with-initconf-in to initdir to install the Modules initialization configurations in the configuration directory designated by the —initdir option, the configuration files initrc and modulespath are respectively named modulerc and .modulespath .

Define modulefiles to load by default. Edit initrc configuration file. Modulefiles to load cannot be specified in modulespath file. Add there all the modulefiles you want to load by default at Modules initialization time.

Add one line mentioning each modulefile to load prefixed by the module load command:

By default, the modules specified on the —with-loadedmodules installation option are automatically defined for load in initrc .

Alternatively, if users have module collections saved in their HOME directory, you may prefer restoring their default collection when Modules initializes rather loading the default module list:

In fact you can add to the initrc configuration file any kind of supported module command, like module config commands to tune module‘s default behaviors. This configuration way is recommended over directly modifying the shell initialization scripts.

If you go through the above steps you should have a valid setup tuned to your needs. After that you still have to write modulefiles to get something to load and unload in your newly configured Modules setup. In case you want to achieve a specific setup, some additional steps may be required:

1. In case the configuration you expect cannot be achieved through the initrc configuration file, you may review and tune the initialization scripts. These files are located in the directory designated by the —initdir option. Beware that these scripts could be overwritten when upgrading to a newer version of Modules, so configuration should be done through the initrc file as far as possible.
2. If you want to alter the way the modulecmd.tcl script operates, the siteconfig.tcl script may be used. This Tcl file is located in the directory designated by the —etcdir option. Every time the module command is called, it executes the modulecmd.tcl script which in turns sources the siteconfig.tcl script during its startup phase. The site-specific configuration script could override default configuration values and more largely could supersede all procedures defined in modulecmd.tcl to obtain specific behaviors.
3. Prior running the module sub-command specified as argument, the modulecmd.tcl script evaluates the global run-command files. These files are either the rc file in the directory designated by the —etcdir option, the file designated in the MODULERCFILE environment variable or the user-specific RC file located in $HOME/.modulerc . The RC files are modulefiles (limited to a subset of the modulefile Tcl commands ) that could define global module aliases, virtual modules or module properties such as tags, forbidding rules, etc.

To learn more about siteconfig and run-command files, see the Modulecmd startup section in module reference manual. You may also look at the available setup recipes to get concrete deployment examples of these files.

Build and installation options¶

Options available at the ./configure installation step are described below. These options enable to choose the installation paths and the features to enable or disable. You can also get a description of these options by typing ./configure —help .

Fine tuning of the installation directories (the default value for each option is displayed within brakets):

Directory for executables reachable by users [ PREFIX/bin ]

Base directory to set the man and doc directories [ PREFIX/share ]

Directory to host documentation other than man pages like README, license file, etc [ DATAROOTDIR/doc ]

Directory for the executable configuration scripts [ PREFIX/etc ]

New in version 4.1.

Directory for the per-shell environment initialization scripts [ PREFIX/init ]

Directory for object code libraries like libtclenvmodules.so [ PREFIX/lib ]

Directory for executables called by other executables like modulecmd.tcl [ PREFIX/libexec ]

Directory to host man pages [ DATAROOTDIR/man ]

Directory of main modulefiles also called system modulefiles [ PREFIX/modulefiles ]

New in version 4.0.

Installation root directory [ /usr/local/Modules ]

Directory to host Vim addon files [ DATAROOTDIR/vim/vimfiles ]

New in version 4.3.

Optional Features (the default for each option is displayed within parenthesis, to disable an option replace enable by disable for instance —disable-set-manpath ):

Activate the advanced module version specifiers which enables to finely select module versions by specifying after the module name a version constraint prefixed by the @ character. This option also allows to specify module variants. (default=yes)

New in version 4.4.

Changed in version 5.0: Configuration option default set to yes

Append rather prepend binary directory to the PATH environment variable when the —enable-set-binpath option is enabled. (default=no)

New in version 4.2.

Append rather prepend man page directory to the MANPATH environment variable when the —enable-set-manpath option is enabled. (default=no)

New in version 4.2.

Set modulecmd.tcl to automatically apply automated modulefiles handling actions, like loading the pre-requisites of a modulefile when loading this modulefile. (default=yes)

New in version 4.2.

Changed in version 5.0: Configuration option default set to yes

When performing an avail sub-command, include in search results the matching modulefiles and directories and recursively the modulefiles and directories contained in these matching directories when enabled or limit search results to the matching modulefiles and directories found at the depth level expressed by the search query if disabled. (default=yes)

New in version 4.3.

Control if output should be colored by default or not. A value of yes equals to the auto color mode. no equals to the never color mode. (default=yes)

New in version 4.3.

Changed in version 5.0: Configuration option default set to yes

Install the documentation files in the documentation directory defined with the —docdir option. This feature has no impact on manual pages installation. Disabling documentation file installation is useful in case of installation process handled via a package manager which handles by itself the installation of this kind of documents. (default=yes)

New in version 4.0.

Install some modulefiles provided as example in the system modulefiles directory defined with the —modulefilesdir option. (default=yes)

New in version 4.0.

Allow to specify module versions by their starting part, i.e. substring separated from the rest of the version string by a . character. (default=yes)

New in version 4.4.

Changed in version 5.0: Configuration option default set to yes

Define an implicit default version, for modules with none explicitly defined, to select when the name of the module to evaluate is passed without the mention of a specific version. When this option is disabled the name of the module passed for evaluation should be fully qualified elsewhere an error is returned. (default=yes)

New in version 4.3.

Implicitly define a prereq or a conflict requirement toward modules specified respectively on module load or module unload commands in modulefile. (default=yes)

New in version 4.7.

Build and install the Modules Tcl extension library which provides optimized Tcl commands for the modulecmd.tcl script. (default=yes)

New in version 4.3.

Enable check of the version specified right after Modules magic cookie ( #%Module ) in modulefiles, which defines the minimal version of the Modules tool to use in order to evaluate the modulefile. (default=yes)

New in version 4.7.

Define the ml command, a handy frontend to the module command, when Modules initializes. (default=yes)

New in version 4.5.

Set the module paths defined by —with-modulepath option in a modulespath file (following C version fashion) within the initialization directory defined by the —etcdir option rather than within the initrc file. Or respectively, if option —with-initconf-in has been set to initdir , in a .modulespath file within the configuration directory defined by the —initdir option rather than within the modulerc file. (default=no)

New in version 4.0.

Changed in version 4.3: Option —enable-modulespath added

Support multilib systems by looking in modulecmd.tcl at an alternative location where to find the Modules Tcl extension library depending on current machine architecture. (default=no)

New in version 4.6.

Enable all new features that are disabled by default due to the substantial behavior changes they imply on Modules 5. This option does not enable other configuration option currently. (default=no)

New in version 4.7.

Changed in version 5.0: Configuration option has been reset following major version change as —enable-auto-handling , —enable-color , —with-icase=search , —enable-extended-default and —enable-advanced-version-spec are set by default on Modules 5.

Generate code in module function definition to add support for the environment variable quarantine mechanism (default=no)

New in version 4.1.

Changed in version 5.0: Configuration option default set to no

Prepend binary directory defined by the —bindir option to the PATH environment variable in the shell initialization scripts. (default=yes)

New in version 4.0.

Prepend man page directory defined by the —mandir option to the MANPATH environment variable in the shell initialization scripts. (default=yes)

New in version 4.0.

Set when module function is defined the shell startup file to ensure that the module function is still defined in sub-shells. (default=no)

New in version 4.3.

Changed in version 5.0: Configuration option default set to no

Generate code in module function definition to add support for silencing shell debugging properties (default=no)

New in version 4.2.

Changed in version 5.0: Configuration option default set to no

Append Modules version to installation prefix and deploy a versions modulepath shared between all versioning enabled Modules installation. A modulefile corresponding to Modules version is added to the shared modulepath and enables to switch from one Modules version to another. (default=no)

Install the Vim addon files in the Vim addons directory defined with the —vimdatadir option. (default=yes)

New in version 4.3.

Activate workaround for issue #277 related to Tcsh history mechanism which does not cope well with default module alias definition. Note that enabling this workaround solves Tcsh history issue but weakens shell evaluation of the code produced by modulefiles. (default=no)

New in version 4.3.

Install all required files for Windows platform ( module, ml and envml command batch file and cmd.cmd initialization script). (default=no)

New in version 4.5.

Optional Packages (the default for each option is displayed within parenthesis, to disable an option replace with by without for instance —without-modulepath ):

Specify the content to report on avail sub-command regular output in addition to the available module names. Elements accepted in LIST are: modulepath , alias , dirwsym , sym , tag and key (elements in LIST are separated by : ). The order of the elements in LIST does not matter. (default= modulepath:alias:dirwsym:sym:tag:key )

New in version 4.7.

Specify the content to report on avail sub-command terse output in addition addition to the available module names. Elements accepted in LIST are: modulepath , alias , dirwsym , sym , tag and key (elements in LIST are separated by : ). The order of the elements in LIST does not matter. (default= modulepath:alias:dirwsym:sym:tag )

New in version 4.7.

List of paths to look at when searching the location of tools required to build and configure Modules (default= /usr/bin:/bin:/usr/local/bin )

New in version 4.2.

Default color set to apply if terminal background color is defined to dark . SGRLIST follows the same syntax than used in LS_COLORS . Each element in SGRLIST is an output item associated to a Select Graphic Rendition (SGR) code. Elements in SGRLIST are separated by : . Output items are designated by keys.

Items able to be colorized are: highlighted element ( hi ), debug information ( db ), trace information ( tr ) tag separator ( se ); Error ( er ), warning ( wa ), module error ( me ) and info ( in ) message prefixes; Modulepath ( mp ), directory ( di ), module alias ( al ), module variant ( va ), module symbolic version ( sy ) and module default version ( de ).

Module tags can also be colorized. The key to set in the color palette to get a graphical rendering of a tag is the tag name or the tag abbreviation if one is defined for tag. The SGR code applied to a tag name is ignored if an abbreviation is set for this tag thus the SGR code should be defined for this abbreviation to get a graphical rendering. Each basic tag has by default a key set in the color palette, based on its abbreviated string: auto-loaded ( aL ), forbidden ( F ), hidden and hidden-loaded ( H ), loaded ( L ), nearly-forbidden ( nF ), sticky ( S ) and super-sticky ( sS ).

New in version 4.3.

Changed in version 4.6: Output item for trace information ( tr ) added

Changed in version 4.7: Output items for module tags auto-loaded ( aL ), forbidden ( F ), hidden and hidden-loaded ( H ), loaded ( L ), nearly-forbidden ( nF ), sticky ( S ) and super-sticky ( sS ) added

Changed in version 4.8: Output item for module variant ( va ) added

Name or full path of default editor program to use to open modulefile through the edit sub-command. (default= vi )

New in version 4.8.

Apply a case insensitive match to module specification on avail , whatis and paths sub-commands (when set to search ) or on all module sub-commands and modulefile Tcl commands for the module specification they receive as argument (when set to always ). Case insensitive match is disabled when this option is set to never . (default= search )

New in version 4.4.

Changed in version 5.0: Configuration option default set to search

Location where to install Modules initialization configuration files. Either initdir or etcdir (default= etcdir )

New in version 4.1.

Changed in version 5.0: Configuration option default set to etcdir

Default color set to apply if terminal background color is defined to light . Expect the same syntax than described for —with-dark-background-colors . (default= hi=1:db=2:tr=2:se=2:er=31:wa=33:me=35:in=34:mp=1;34:di=34:al=36:va=33:sy=35:de=4:cm=32:aL=107:L=47:H=2:F=101:nF=103:S=106:sS=104 )

New in version 4.3.

Changed in version 4.6: Output item for trace information ( tr ) added

Changed in version 4.7: Output items for module tags auto-loaded ( aL ), forbidden ( F ), hidden and hidden-loaded ( H ), loaded ( L ), nearly-forbidden ( nF ), sticky ( S ) and super-sticky ( sS ) added

Changed in version 4.8: Output item for module variant ( va ) added

Specify the content to report on list sub-command regular output in addition to the loaded module names. Elements accepted in LIST are: header , idx , variant , sym , tag and key (elements in LIST are separated by : ). The order of the elements in LIST does not matter. (default= header:idx:variant:sym:tag:key )

New in version 4.7.

Changed in version 4.8: Element variant added and set by default

Specify the content to report on list sub-command terse output in addition to the loaded module names. Elements accepted in LIST are: header , idx , variant , sym , tag and key (elements in LIST are separated by : ). The order of the elements in LIST does not matter. (default= header )

New in version 4.7.

Changed in version 4.8: Element variant added

Default modulefiles to load at Modules initialization time. Each modulefile in this list should be separated by : . Defined value is registered in the initrc configuration file or in the modulerc file if —with-initconf-in is set to initdir . (default=no)

New in version 4.0.

Ignore environment variable superseding value for the listed configuration options. Accepted option names in CONFIGLIST are extra_siteconfig and implicit_default (each option name should be separated by whitespace character). (default=no)

New in version 4.3.

Default path list to setup as the default modulepaths. Each path in this list should be separated by : . Defined value is registered in the initrc or modulespath configuration file, depending on the —enable-modulespath option. These files are respectively called modulerc and .modulespath if —with-initconf-in is set to initdir . The path list value is read at initialization time to populate the MODULEPATH environment variable. By default, this modulepath is composed of the directory set for the system modulefiles (default= PREFIX/modulefiles or BASEPREFIX/$MODULE_VERSION/modulefiles if versioning installation mode enabled)

New in version 4.0.

Location of the main Modules package file directory (default= PREFIX )

New in version 4.4.

Define the number of days a module is considered nearly forbidden prior reaching its expiry date. VALUE should be an integer comprised between 0 and 365. (default= 14 )

New in version 4.6.

Name or full path of default pager program to use to paginate informational message output (can be superseded at run-time by environment variable) (default= less )

New in version 4.1.

Settings to apply to default pager program (default= -eFKRX )

New in version 4.1.

Name or full path of Python interpreter command to set as shebang for helper scripts. (default= python )

New in version 4.5.

Environment variables to put in quarantine when running the module command to ensure it a sane execution environment (each variable should be separated by space character). A value can eventually be set to a quarantine variable instead of emptying it. (default=no)

New in version 4.1.

When searching for a module with avail sub-command, match query string against module name start ( starts_with ) or any part of module name string ( contains ). (default= starts_with )

New in version 4.3.

Define the abbreviation to use when reporting each module tag. Each element in ABBRVLIST is a tag name associated to an abbreviation string (elements in ABBRVLIST are separated by : ). (default= auto-loaded=aL:loaded=L:hidden=H:hidden-loaded=H:forbidden=F:nearly-forbidden=nF:sticky=S:super-sticky=sS )

New in version 4.7.

Define the tags whose graphical rendering should be applied over their name instead of over the name of the module they are attached to. Each element in TAGLIST is a tag name or abbreviation (elements in TAGLIST are separated by : ). (default=)

New in version 4.7.

Directory containing the Tcl configuration script tclConfig.sh . Useful to compile Modules Tcl extension library if this file cannot be automatically found in default locations.

Directory containing the Tcl header files. Useful to compile Modules Tcl extension library if these headers cannot be automatically found in default locations.

Name or full path of Tcl interpreter shell (default= tclsh )

New in version 4.0.

The terminal background color that determines the color set to apply by default between the dark background colors or the light background colors (default= dark )

New in version 4.3.

When unloading a module if multiple loaded modules match the request, unload module loaded first ( returnfirst ) or module loaded last ( returnlast ) (default= returnlast )

New in version 4.3.

Define the shortcut characters that could be used to specify variant names. Each element in SHORTCUTLIST is a variant name associated to a shortcut character (e.g., foo=% ). Shortcuts cannot exceed a length of 1 character and cannot be alphanumeric characters ([A-Za-z0-9]) or characters with already a special meaning ([+

/@=-]). Elements in SHORTCUTLIST are separated by : . (default=)

New in version 4.8.

Specify default message verbosity. accepted values are silent , concise , normal , verbose , verbose2 , trace , debug and debug2 . (default= normal )

Источник