Intermapper Service Management for Linux Systems

Intermapper includes three services: Intermapper Server, Intermapper DataCenter, and Intermapper Flows. On each Microsoft Windows and macOS system, Intermapper Control Center (IMCC) provides a user interface client for starting and stopping Intermapper Server and Intermapper Flows. In addition, on Microsoft Windows systems, these services can be controlled from the Microsoft Windows Services application. On macOS, Intermapper Data Center (IMDC) can be started and stopped using the following commands respectively:

• /usr/local/imdc/sbin/imdc start

• /usr/local/imdc/sbin/imdc stop

On Linux systems, the three Intermapper services are controlled through systemd, which is the Linux service manager facility. For information necessary to start and stop the Intermapper services on a Linux host, using the systemd command line client (systemctl), see the Intermapper Installation Guide and the Intermapper User Guide.

This section provides additional information on the system administration of a Linux Intermapper host of the Linux service configuration.

Service Definitions

Under systemd, each Linux host service is described by a service unit file. The service unit files for the Intermapper services are in the /usr/local/share/intermapper/units directory. There is a file for each service (intermapperd.service, imdc.service, and imflows.service. The files are copied into the /etc/systemd/system systemd directory by the Intermapper installation process which also starts and enables the Intermapper service, the DataCenter service, and (optionally) the Flows service.

For information on how to read and write service definition files, see the systemd.unit(5) and systemd.service(5) Linux manual pages. Make sure you consult the version of the documentation that matches your Linux version as there can be version-specific information.

Although service definition files are written using a stanza-like format, they are case-sensitive, which is the normal Linux convention. Do not include an alias line in the service definition file that matches the service file name.

Some versions of systemd support linking service definition files into the systemd configuration area rather than copying them there, but this is not uniformly supported across target Linux versions for Intermapper. Fortra does not recommend using the systemctl link command for the Intermapper service definition files (even if your Linux system has a more evolved version of systemd) as this can cause confusion to Fortra Technical Support.

systemd Command Line Interface

The primary interface for systemd is the systemctl command line interface. For more information on the systemctl command line interface, see the systemctl(1) Linux manual page. The following commands are used by systemctl where <service> is the name of the service. For example, intermapperd.service.

  • systemctl start <service> starts a service

  • systemctl stop <service> stops a service

  • systemctl status <service> reports the status of a service

  • systemctl restart <service> stops and starts a service

  • systemctl enable <service> enables a service on reboot

  • systemctl disable <service> inhibits a service from restarting on reboot

  • systemctl reload <service> requests a running service to reload its configuration

  • systemctl daemon-reload recaches changes to the systemd configuration

  • systemctl reset-failed clears a service failure statuses

  • systemctl list-units displays a service status (append "-a" to include all services)

You must run these commands as a Linux super-user (root). If you try to change the systemd configuration as a non-root user, then, depending on your administration policy tool (if any), you are asked to authenticate as an appropriately authorized user before the request can be performed.

Intermapper Service Definitions

Two of the Intermapper services (Intermapper Data Center and Intermapper Flows) are configured as forking services and the Type field of their definition is set to forking. This means that they take advantage of the systemd provision to retain control of the services even if their primary processes fork and delegate their primary service function to the child process (as was required by the traditional Linux service management). This does not result in any significant loss of service management functionality and each of these services records its presence in a pid-file (a plain text file containing theprocess-id) as reflected by the PIDFile clause in its service definition.

By contrast, the Intermapper server has a service definition file that uses the default service type, which, depending on the systemd version, is either simple or exec. The --no-daemonize option is passed on the execution command line specified in the service definition ExecStart clause. This is consistent with earlier versions of Intermapper, but restarting the service automatically on failure (formerly delegated to an Intermapper-supplied shell script) is now handled by systemd itself through use of the Restart, RestartSec, StartLimitInterval, and StartLimitBurst clauses of the service definition file.

The Linux Intermapper host system administrator can configure the Intermapper services by editing the service definition files using the generic systemd documentation. Doing this should preserve the original content of the service unit files that are in /usr/local/share/intermapper/units as a reference in case you need to recover the standard configuration. Use the systemd commands described in the previous section to install and test the local configuration changes.