cancel
Showing results for 
Search instead for 
Did you mean: 

EFM service start error

SOLVED
Adventurer

EFM service start error

I used [efm encrypt] to encrypt a password for cluster, and pasted the password into the cluster properties file.

when I start the EFM service.I can not start the service and ocuured an error. what should I do to resolve the error?

 

[root@localhost bin]# ./efm encrypt test
This utility will generate an encrypted password for you to place in your
EFM cluster property file.
Please enter the password and hit enter:

Please enter the password again to confirm:

The encrypted password is: 872a5186812a1c7d70712c6ec962caca

Please paste this into your cluster properties file.
        db.password.encrypted=872a5186812a1c7d70712c6ec962caca

[root@localhost efm-2.1]# cat efm.properties
# Copyright EnterpriseDB Corporation, 2013-2016. All Rights Reserved.

# Do not use quotes around property values in this file.

# The full license to run failover manager.
efm.license=

# The value for the password property should be the output from
# 'efm encrypt' -- do not include a cleartext password here. To
# prevent accidental sharing of passwords among clusters, the cluster
# name is incorporated into the encrypted password. If you change
# the cluster name (the name of this file), you must encrypt the
# password again with the new name.
# The db.port property must be the same for all nodes.
db.user=enterprisedb
db.password.encrypted=872a5186812a1c7d70712c6ec962caca
db.port=5444
db.database=edb

# This property tells EFM which OS user owns the $PGDATA dir for the
# 'db.database'.  By default, the owner is either 'postgres' for PostgreSQL
# or 'enterprisedb' for EDB Postgres Advanced Server.  However, if you
# have configured your db to run as a different user, you will need to
# copy the /etc/sudoers.d/efm-XX conf file to grant the
# necessary permissions to your db owner.
#
# This username must have write permission to the 'db.recovery.conf.dir'
# specified below.
db.service.owner=enterprisedb

# Specify the proper service name in order to use service commands rather
# than pg_ctl to start/stop/restart a database. For example, if this property
# is set, then 'service <name> restart' or 'systemctl restart <name>'
# (depending on OS version) will be used to restart the database rather than pg_ctl.
# This property is required unless db.bin is set.
db.service.name=ppas-9.4

# Specify the directory containing the pg_ctl command, for example:
# /usr/pgsql-9.5/bin. Unless the db.service.name property is used, the pg_ctl
# command is used to start/stop/restart databases as needed after a
# failover or switchover. This property is required unless db.service.name
# is set.
db.bin=/opt/PostgresPlus/9.4AS/bin

# Specify the location of the db recovery.conf file on the node. On
# a standby node, the trigger file location is read from the file in
# this directory. After a failover, the recovery.conf files on
# remaining standbys are changed to point to the new master db (a copy
# of the original is made first). On a master node, a recovery.conf file will
# be written during failover and promotion to ensure that the master node can
# not be restarted as the master database.
db.recovery.conf.dir=/opt/PostgresPlus/9.4AS/data

# Use the jdbc.ssl property to enable ssl for EFM connections. Setting
# this property to true will force the agents to use 'ssl=true' for all
# JDBC database connections (to both local and remote databases).
# When jdbc.ssl is true (and ssl is enabled), the jdbc.ssl.mode property will
# determine how server certificates are handled. Valid values are:
#
# verify-ca - EFM will perform CA verification before allowing the
#             certificate. This is the default value in case ssl
#             is used and the mode property is not set.
# require   - Verification will not be performed on the server certificate.
jdbc.ssl=false
jdbc.ssl.mode=verify-ca

# Email address(es) for notifications. The value of this property must
# be the same across all agents. Multiple email addresses must
# be separated by space. If using a notification script instead,
# this property can be left blank.
user.email=test@test.com

# Absolute path to script run for user notifications.
#
# This is an optional user-supplied script that can be used for
# notifications instead of email. This is required if not using
# email notifications. Either/both can be used. The script will
# be passed two parameters: the message subject and the message body.
script.notification=

# This property specifies the ip address and port that jgroups
# will bind to on this node. The value is of the form <ip>:<port>.
# Note that the port specified here is used for communicating with
# other nodes, and is not the same as the admin.port above, used
# only to communicate with the local agent to send control signals.
bind.address=192.168.65.133:5430

# This property controls the port binding of the administration server
# which is used for some commands (ie cluster-status).
admin.port=5431

# Specifies whether or not this is a witness node. Witness nodes
# do not have local databases running.
is.witness=false

# These properties apply to the connection(s) EFM uses to monitor
# the local database. Every 'local.period' seconds, a database check
# is made in a background thread. If the main monitoring thread does
# not see that any checks were successful in 'local.timeout' seconds,
# then the main thread makes a final check with a timeout value
# specified by the 'local.timeout.final' value. All values are in seconds.
# Whether EFM uses single or multiple connections for database checks
# is controlled by the 'db.reuse.connection.count' property.
local.period=10
local.timeout=60
local.timeout.final=10

# Timeout for a call to check if a remote database is responsive.
# For example, this is how long a standby would wait for a
# DB ping request from itself and the witness to the master DB
# before performing failover.
remote.timeout=10

# The total amount of time in seconds to wait before determining that
# a node has failed or been disconnected from this node.
#
# The value of this property must be the same across all agents.
node.timeout=50

# This is the address of a well-known server that EFM can ping in an
# effort to determine network reachability issues.  It might be the IP
# address of a nameserver within your corporate firewall or another server
# that *should* always be reachable via a 'ping' command from each of the
# EFM nodes.
#
# There are many reasons why this node might not be considered reachable:
# firewalls might be blocking the request, ICMP might be filtered out,
# etc.
#
# Do not use the IP address of any node in the EFM cluster (master, standby,
# or witness because this ping server is meant to provide an additional
# layer of information should the EFM nodes lose sight of each other.
#
# The installation default is Google's DNS server.
pingServerIp=8.8.8.8

# This command will be used to test the reachability of certain nodes.
#
# Do not include an IP address or hostname on the end of this command - it
# will be added dynamically at runtime with the values contained in 'virtualIp'
# and 'pingServer'.
#
# Make sure this command returns reasonably quickly - test it from a shell
# command line first to make sure it works properly.
pingServerCommand=/bin/ping -q -c3 -w5

# Have the first node started automatically add the addresses from
# its .nodes file to the allowed host list. This will make it
# faster to start the cluster when the initial set of hosts
# is already known.
auto.allow.hosts=false

# This property controls how many times a database connection is reused
# before creating a new one. If set to zero, a new connection will be
# created every time an agent pings its local database.
db.reuse.connection.count=0

# Whether or not failover will happen automatically when the master
# fails. Set to false if you want to receive the failover notifications
# but not have EFM actually perform the failover steps.
# The value of this property must be the same across all agents.
auto.failover=true

# After a standby is promoted, failover manager will attempt to
# update the remaining standbys to use the new master. Failover
# manager will back up recovery.conf, change the host parameter
# of the primary_conninfo entry, and restart the database. The
# restart command is contained in either the efm_db_functions or
# efm_root_functions file; default when not running db as an os
# service is: "pg_ctl restart -m fast -w -t <timeout> -D <directory>"
# where the timeout is the local.timeout property value and the
# directory is specified by db.recovery.conf.dir. To turn off
# automatic reconfiguration, set this property to false.
auto.reconfigure=true

# A standby with this set to false will not be added to the failover
# priority list, and so will not be available for promotion. The
# property will be used whenever an agent starts as a standby or
# resumes as a standby after being idle. After startup/resume, the
# node can still be added or removed from the priority list with the
# 'efm set-priority' command. This property is required for all
# non-witness nodes.
promotable=true

# Instead of setting specific standbys as being unavailable for
# promotion, this property can be used to set a minimum number
# of standbys that will not be promoted. Set to one, for example,
# promotion will not happen if it will drop the number of standbys
# below this value. This property must be the same on each node.
minimum.standbys=0

# Time in seconds between checks to see if a promoting database
# is out of recovery.
recovery.check.period=2

# Period in seconds for IDLE agents to try to resume monitoring after
# a database failure. Set to 0 for agents to not try to resume
# (in which case the 'efm resume <cluster>' command is used after
# bringing a database back up).
auto.resume.period=0

# This is the IP and netmask that will be remapped during fail over.  If you do
# not use VIPs as part of your failover solution, then leave these properties
# blank to disable EFM's support for VIP processing (assigning, releasing,
# testing reachability, etc).
#
# If you enable VIP, then all three properties are required.
#
# The address and netmask must be the same across all agents.
# The 'interface' value must contain the secondary virtual ip id (ie ":1", etc).
virtualIp=
virtualIp.interface=
virtualIp.netmask=

# Absolute path to fencing script run during promotion
#
# This is an optional user-supplied script that will be run during
# failover on the standby database node.  If left blank, no action will
# be taken.  If specified, EFM will execute this script before promoting
# the standby. The script is run as the efm user.
#
# Parameters can be passed into this script for the failed master and
# new primary node addresses. Use %p for new primary and %f for failed
# master. On a node that has just been promoted, %p should be the same
# as the node's efm binding address.
#
# Example:
# script.fence=/somepath/myscript %p %f
#
# NOTE: FAILOVER WILL NOT OCCUR IF THIS SCRIPT RETURNS A NON-ZERO EXIT CODE.
script.fence=

# Absolute path to fencing script run after promotion
#
# This is an optional user-supplied script that will be run after
# failover on the standby node after it has been promoted and
# is no longer in recovery. The exit code from this script has
# no effect on failover manager, but will be included in a notification
# sent after the script executes.  The script is run as the efm user.
#
# Parameters can be passed into this script for the failed master and
# new primary node addresses. Use %p for new primary and %f for failed
# master. On a node that has just been promoted, %p should be the same
# as the node's efm binding address.
#
# Example:
# script.post.promotion=/somepath/myscript %f %p
script.post.promotion=

# Absolute path to resume script
#
# This script is run whenever an IDLE agent is resumed and starts
# monitoring its local database.
script.resumed=

# Absolute path to script run after database failure
#
# This is an optional user-supplied script that will be run after
# an agent detects that its local database has failed. The script
# is run as the efm user.
script.db.failure=

# Absolute path to script run on isolated master
#
# This is an optional user-supplied script that will be run after
# a master agent detects that it has been isolated from the majority
# of the efm cluster. The script is run as the efm user.
script.master.isolated=

# Command to use in place of 'sudo' if desired when efm runs
# the efm_db_functions, efm_root_functions, or efm_address scripts.
# Sudo is used in the following ways by efm:
#
# sudo /usr/efm-<version>/bin/efm_address <arguments>
# sudo /usr/efm-<version>/bin/efm_root_functions <arguments>
# sudo -u <db service owner> /usr/efm-<version>/bin/efm_db_functions <arguments>
sudo.command=sudo

# Logging levels for JGroups and EFM.
# Valid values are: FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE
# Default value: INFO
# It is not necessary to increase these values unless debugging a specific
# issue. If nodes are not discovering each other at startup, increasing
# the jgroups level to FINER will show information about the TCP connection
# attempts that may help diagnose the connection failures.
jgroups.loglevel=INFO
efm.loglevel=INFO

# Extra information that will be passed to the JVM when starting the agent.
jvm.options=-Xmx32m

 

[root@localhost efm-2.1]# cat efm.nodes
# List of node addressSmiley Tongueort combinations separated by whitespace.
# The list should include at least the membership coordinator's address.
192.168.65.132:5430
192.168.65.135:5430

 

[root@localhost efm-2.1]# service efm-2.1 start
Starting local efm-2.1 service:                            [FAILED]

[root@localhost efm-2.1]# cat efm.log
2/9/18 10:41:49 PM com.enterprisedb.efm.utils.LockFile lock INFO: created lock file: /var/lock/efm-2.1/efm.lock

2/9/18 10:41:49 PM com.enterprisedb.efm.exec.ExecUtil performExec INFO: [chmod 644 /var/lock/efm-2.1/efm.lock]

2/9/18 10:41:49 PM com.enterprisedb.efm.exec.ExecUtil performExec INFO: ProcessResult{exitValue=0, errorOut='', stdOut=''}

2/9/18 10:41:49 PM com.enterprisedb.efm.utils.LockFile lock INFO: Starting lock monitor for: /var/lock/efm-2.1/efm.lock

2/9/18 10:41:49 PM com.enterprisedb.efm.nodes.EfmNode commonShutdown INFO: Starting shutdown.

2/9/18 10:41:49 PM com.enterprisedb.efm.exec.ExecUtil performExec INFO: [sudo /usr/efm-2.1/bin/efm_root_functions deletepidkey efm]

2/9/18 10:41:49 PM com.enterprisedb.efm.exec.ExecUtil performExec INFO: ProcessResult{exitValue=0, errorOut='', stdOut=''}

2/9/18 10:41:49 PM com.enterprisedb.efm.nodes.EfmAgent shutdown INFO: Exiting.

 

[root@localhost efm-2.1]# cat startup-efm.log
[ 2/9/18 10:41:49 PM ] Starting agent.
[ 2/9/18 10:41:49 PM ] Could not decode database password. Check that it has been encrypted properly. Error: Given final block not properly padded
[root@localhost efm-2.1]#

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
EDB Team Member

Re: EFM service start error

Hi MarkMark ,

 

Hope you are doing good.

 

From your properties file name (efm.properties)it appears that the cluster name is efm. But when you encrypted the password you have used 'test' as your cluster name. When encrypting password you need to provide the cluster name.

To encrypt a password, use the command:
#efm encrypt cluster_name

In case you want to keep the cluster name as 'test', you need to change the cluster name in /etc/init.d/efm-2.1 service file.

And also rename the efm.properties, efm.nodes files as test.properties and test.nodes .

You can follow this link for more information.
https://www.enterprisedb.com/docs/en/2.1.2/edbfm/toc.html

Please let us know how it goes.

 

Thanks,

Swagata 

3 REPLIES
Adventurer

Re: EFM service start error

OS version is:

 cat /etc/issue
CentOS release 6.4 (Final)
Kernel \r on an \m

 

java version is:

 

java -version
java version "1.7.0_161"
OpenJDK Runtime Environment (rhel-2.6.12.0.el6_9-x86_64 u161-b00)
OpenJDK 64-Bit Server VM (build 24.161-b00, mixed mode)

Highlighted
EDB Team Member

Re: EFM service start error

Hi MarkMark ,

 

Hope you are doing good.

 

From your properties file name (efm.properties)it appears that the cluster name is efm. But when you encrypted the password you have used 'test' as your cluster name. When encrypting password you need to provide the cluster name.

To encrypt a password, use the command:
#efm encrypt cluster_name

In case you want to keep the cluster name as 'test', you need to change the cluster name in /etc/init.d/efm-2.1 service file.

And also rename the efm.properties, efm.nodes files as test.properties and test.nodes .

You can follow this link for more information.
https://www.enterprisedb.com/docs/en/2.1.2/edbfm/toc.html

Please let us know how it goes.

 

Thanks,

Swagata 

Adventurer

Re: EFM service start error

Hi Swagata Thank you very much. I have resolved it. Best Regards, xiangqian