SeisComP modules


This document describes the difference between command-line and daemon modules.


SeisComP is not a single executable but it provides a set of trunk and standalone modules. Trunk modules can be

Modules are configured by configuration files either to be used directly or to generate its native configuration. Modules that need to convert the configuration or do not use the default configuration options (see below) are called standalone modules. All other modules are called trunk modules.

Examples for standalone modules are seedlink, slarchive and slmon.


In order to start or execute modules without seiscomp exec (see below), the SeisComP SHELL environment variables must be known to the system. The variables and their values can be printed giving the full path to the seiscomp tool. Example:

/home/sysop/seiscomp/bin/seiscomp print env

Daemon Tools

Daemon tools are SeisComP modules that can run automatically in the background without user interaction, e.g., for automatic data acquisition or data processing. The names of all daemon modules are listed when executing the seiscomp tool with list modules:

seiscomp list modules

Daemon modules can be started to run in the background:

seiscomp start scautopick

When starting a daemon module, all verbosity output is logged to log files. Daemon modules can also be executed as command-line tools.

Command-Line Tools

All non-daemon modules are command-line modules. These command-line modules and most daemon modules can be executed on demand from the SHELL command-line. These modules can also be utilities or graphical user interfaces (GUIs). For executing use the full path to the seiscomp tool or, when the SeisComP environment is known, just call the module name along with command-line options, e.g.

seiscomp exec scolv [options]
scolv [options]

Command-line modules are found in @ROOTDIR@/bin/ but they are NOT listed when executing

seiscomp list modules

Using options like -h the list of available command-line options can be learned.

scbulletin -h

In addition, any module configuration parameter can be specified on the command line overriding the configured parameter. For indicating that a module configuration parameter is set on the command line separate the value from the parameter by ‘=’ and provide the full set of sections separated by ‘.’. Example:

scolv --picker.loadAllPicks=true

When executing a module, all verbosity output is logged to log files. The logging level can be controlled by configuration or by the command-line option -v.

scbulletin -vvvv

Detailed debugging information can also be printed on the command line during runtime using the --debug option:

scbulletin --debug

When starting a daemon module all verbosity output is stored in @LOGDIR@ or $SEISCOMP_ROOT/var/log. Daemon modules can also be executed as command-line tools.


Each standalone module tries to read from three module configuration files whereas trunk modules try to read the six files. Note that configuration parameters defined earlier are overwritten if defined in files read in later:



















In addition to the module configuration files some modules such as seedlink or scautopick consider bindings. Bindings provide parameters specific to stations. They are configured as per-station bindings or profiles used for multiple stations.

The global configuration section describes all available global configuration parameters for a trunk module. Modules typically do not make use of all available global parameters because they may be disabled, e.g., the messaging component. So the configuration of the messaging server is disabled, too.

The concept section Configuration provides more details about configurations.


Whenever operated, modules report the state of operation to log files. Trunk modules report the module and the start up log to @LOGDIR@/[module].log and @ROOTDIR@/var/log/[module].log, respectively. Standalone modules log to @ROOTDIR@/var/log/[module].log only. The log files are rotated and the level of detail can be configured by logging.level. More parameters in logging.* provide more control over logging, e.g., the log file rotation.

Alias Modules

Many trunk and standalone modules allow generating aliases as symbolic links to another module. These aliases are useful for running multiple instances of the same module with different configuration.

Alias modules can be created or removed using the seiscomp tool by providing the commands alias create or alias remove, respectively. Read the documentation of seiscomp for the details.