module
Name
module — manage loaded modules online
Synopsis
module hooks
module list
Description
The module list command displays a full list of all loaded modules, as illustrated below:
16:48:23 /tmp/2025> module list Module: ec_logger:ec_logger Scope_Name: ec_logger Instance_Name: ec_logger Enabled: enabled API: Logger Name: ec_logger.c Description: Momentum minimalistic logging module Module: bounce_logger:bounce_logger Scope_Name: bounce_logger Instance_Name: bounce_logger Enabled: enabled API: Logger Name: $RCSfile: bounce_logger.c,v $ Description: Eclerity minimalistic logging module $Revision: 1.51 $ Module: statp:statp Scope_Name: statp Instance_Name: statp Enabled: enabled API: Generic Name: stats_producer.c Description: Stats producer module Module: ds_core Scope_Name: ds_core Enabled: enabled API: Singleton Name: ds_core.c Description: generic datasource module ...
In addition to supplying information about your configuration, the scope name and the instance name shown by the module list command are required when issuing module-specific commands. For more information see the section called “Module-specific Commands”.
module hooks displays all the dynamic hooks in the system, along with each hook’s prototype. The output should be similar to the following:
core_config_get_domain_bounces_inline_original_data int(generic_module_infrastructure*,int*,constchar*,void**) core_config_get_reserve_maintenance_interval_data int(generic_module_infrastructure*,int*,void**) ...
Module-specific Commands
Before issuing commands to a module from the system console, you need to know whether a module is a "Singleton" or not. You can determine this using the module list command. For non-singleton modules you issue module commands using the Scope_Name (also know as the module name) and the Instance_Name. For example, if you have a bounce_logger module defined in the following way, bounce_logger "bounce_logger1" { ... }
, issue the command bounce_logger:bounce_logger1
reopen logs to reopen the logs. For a list of the modules that have console commands see “Module-Specific Console Commands”.
For modules where the API is defined as a Singleton (the ds_core module, for example) there is no Instance_Name. Issue singleton module commands using the Scope_Name only.
Setting and Getting Module Options
All module-specific commands related to setting or getting module options have been removed in version 3.0. For example, you can no longer set the Sieve cache size in the following way: sieve set cache_size 300 . Again, in order to get or set module options, you need to use the module list command first to determine whether a module is a singleton or not. Use the following syntax to set or get module-specific options: config {set | get} Scope_Name [Instance_Name] option [value] . Note that there is no ‘:
’ between the Scope_Name and the Instance_Name. You cannot specify the Instance_Name if the module is a singleton. For a complete discussion of the config command see config.
In version 3.0, modules no longer have id numbers, so you can not enable or disable them using the command module disable module_number
. Instead use the "config set" syntax, for example, config set bounce_classifier bounce_classifier1
enabled 1 .