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 .