Controlling the Failover Manager service v5

Each node in a Failover Manager cluster hosts a Failover Manager agent that is controlled by a service script. By default, the service script expects to find:

• A configuration file named efm.properties that contains the properties used by the Failover Manager service. Each node of a replication scenario must contain a properties file that provides information about the node.
• A cluster members file named efm.nodes that contains a list of the cluster members. Each node of a replication scenario must contain a cluster members list.

If you're running multiple clusters on a single node, you need to manually create configuration files with cluster-specific names and modify the service script for the corresponding clusters.

The commands that control the Failover Manager service are platform specific.

Using the systemctl utility on RHEL/Rocky Linux/AlmaLinux 8.x or later

On RHEL/Rocky Linux/AlmaLinux 8.x or later, Failover Manager runs as a Linux service named (by default) edb-efm-5.<x>.service that is located in /usr/lib/systemd/system. Each database cluster monitored by Failover Manager runs a copy of the service on each node of the replication cluster.

Use the following systemctl commands to control a Failover Manager agent that resides on a RHEL/Rocky Linux/AlmaLinux 8.x or later host:

systemctl start edb-efm-5.<x>

The start command starts the Failover Manager agent on the current node. The local Failover Manager agent monitors the local database and communicates with Failover Manager on the other nodes. You can start the nodes in a Failover Manager cluster in any order. This command must be invoked by root.

systemctl stop edb-efm-5.<x>

Stop the Failover Manager on the current node. This command must be invoked by root.

systemctl status edb-efm-5.<x>

The status command returns the status of the Failover Manager agent on which it is invoked. You can invoke the status command on any node to instruct Failover Manager to return status and server startup information.

[root@ONE ~]}> systemctl status edb-efm-5.0
● edb-efm-5.0.service - EnterpriseDB Failover Manager 5.0
     Loaded: loaded (/usr/lib/systemd/system/edb-efm-5.0.service; disabled; preset: disabled)
     Active: active (running) since Fri 2025-03-07 19:28:54 UTC; 6s ago
    Process: 10559 ExecStart=/bin/bash -c /usr/edb/efm-5.0/bin/runefm.sh start ${CLUSTER} (code=exited, status=0/SUCCESS)
   Main PID: 10641 (java)
      Tasks: 38 (limit: 50116)
     Memory: 193.1M
        CPU: 2.964s
     CGroup: /docker/c43e0e153c7726711f77b91735d40c26073c4ac9fdd061551669b25b4b3763a9/system.slice/edb-efm-5.0.service
             └─10641 /usr/lib/jvm/java-11-openjdk-11.0.25.0.9-3.el9.aarch64/bin/java -cp /usr/edb/efm-5.0/lib/EFM-5.0-SNAPSHOT.jar -Xmx128m com.enterprisedb.efm.main.ServiceCom>

Mar 07 19:28:49 bnode1 sudo[10750]:      efm : PWD=/ ; USER=postgres ; COMMAND=/usr/edb/efm-5.0/bin/efm_db_functions readpgversion /etc/edb/efm-5.0/efm.properties
Mar 07 19:28:49 bnode1 bash[10624]: 2025-03-07 19:28:49 The local database is not in recovery. Continuing startup in primary mode.
Mar 07 19:28:49 bnode1 bash[10624]: 2025-03-07 19:28:49 Agent logs will be written to /var/log/efm-5.0/efm.log
Mar 07 19:28:49 bnode1 bash[10624]: 2025-03-07 19:28:49 The virtual.ip property is not set, starting EFM with VIP support disabled.
Mar 07 19:28:51 bnode1 bash[10624]: 2025-03-07 19:28:51
Mar 07 19:28:51 bnode1 bash[10624]: 2025-03-07 19:28:51 -------------------------------------------------------------------
Mar 07 19:28:51 bnode1 bash[10624]: 2025-03-07 19:28:51 GMS: address=bnode1-17436(bnode1), cluster=efm, physical address=172.17.0.2:7800
Mar 07 19:28:51 bnode1 bash[10624]: 2025-03-07 19:28:51 -------------------------------------------------------------------
Mar 07 19:28:54 bnode1 bash[10624]: 2025-03-07 19:28:54 Now monitoring database.
Mar 07 19:28:54 bnode1 systemd[1]: Started EnterpriseDB Failover Manager 5.0