Layer7 API Management

 View Only

API Gateway unable to start after restoring from backup 

Jul 03, 2015 10:26 AM



The CA API Gateway has a native backup and restoration suit that can take full Gateway backups or backup specific components of the API Gateway appliance. A defect in the product may cause the API Gateway to fail to start after restoring from a backup image.




The most common symptom of this defect is caused by the API Gateway reporting a status of WONT_START in the Gateway configuration menu. The following log entries may also be seen in the Process Controller log:

com.l7tech.server.processcontroller.ProcessController: default crashed on startup with exit code 0

com.l7tech.server.processcontroller.ProcessController: default crashed on startup; copying its output:

com.l7tech.server.processcontroller.ProcessController: default wouldn't start; restarting...


The strongest indicator of this behavior would be verifying the permissions of certain configuration files after a restore. Navigate to /opt/SecureSpan/Gateway/node/default/etc/conf and observe whether the files have the following permissions:

-rw-rw-r-- 1 layer7 gateway 537 Apr 27 14:48

-rw------- 1 layer7 gateway  42 Feb 26 01:28 omp.dat

-rw------- 1 layer7 gateway  53 Feb 26 01:28

-rw------- 1 layer7 gateway 737 Feb 26 01:28


If the permissions are as described as above then the API Gateway in question has been impacted by this defect.




This behavior is caused by a defect in the product that does not set certain file permissions appropriately. Log in to the API Gateway via SSH or a console connection and perform the following procedure:

  1. Log in to the API Gateway as the ssgconfig user
  2. Select Option #3: Use a privileged shell (root)
  3. Move to a specific configuration directory: cd /opt/SecureSpan/Gateway/node/default/etc/conf/
  4. Modify the permissions of specific files: chmod 640 omp.dat
  5. Restart the API Gateway appliance

This defect has been registered with the API Management engineering staff and has been assigned development incident identifier SSG-9735. This defect is valid for all currently supported versions of the API Gateway.

0 Favorited
0 Files

Tags and Keywords


Jan 20, 2020 08:45 AM

This defect is still present in 9.4CR3.

I have done a full backup/restore, when I check network configuration via the appliance it says there is "no interface found". When I check in /etc/sysconfig/network-scripts then there is a ifcfg-eth0 file present with the "new" network config.
I checked the mentioned property files and changed the permissions to 640 as mentioned. After reboot I still don't see the interfaces in the appliance menu.

Anyone seen this before and knows resolution ?

Dec 26, 2018 08:29 AM

Seems like this defect is still present in 9.3?


Is there another fix when the above method fails?

May 02, 2018 11:30 AM

I can not believe this still has not been resolved in version 9.1 when this issue was discovered in 2015. 

Dec 29, 2015 08:28 AM

A node would have needed to been configured in order to get the database to be created for the first time. That said--your best bet here would be to configure a node via the Gateway configuration menu and then set it to "disabled." This process can be found here: Deactivating a Cluster Node - CA API Gateway - 9.0 - CA Technologies Documentation. Disabling the node after configuring it will allow the database to exist, a file to be present, but prevent it from processing any message traffic.

Dec 29, 2015 01:49 AM

Hello Chris,


I have another question on this, Is there a way to backup the Gateway, when it is only being used for MySQL?


i.e., Customer is using one of the Gateways to hold the External Gateway DB. In this case, is it possible to use the ssgbackup utlity to backup the DB ?


It generally checks for "" file, which doesn't exist on that Gateway, as it is not configured as Gateway.


Any inputs ??




Dec 28, 2015 10:27 AM

Thanks Chris..!

Related Entries and Links

No Related Resource entered.