Troubleshooting a Siebel Cloud Manager Instance

The SCM instance might not run in any of the following cases:

When the OCI configuration is not set up correctly, access to the Siebel Cloud Manager (SCM) instance is blocked, and the system returns a safe response, as shown below:
```
{
    "data": {
        "log_path": "logs/common_logger.log"
    },
    "message": "The request could not be completed. Review the referenced logs for details.",
      "status": "failed"
}
```
In the above example, the "message" field is intentionally general.
The data.log_path parameter value identifies the relative path to the SCM log file that contains detailed diagnostic information about the failure. This path is relative to the SCM home directory; it is neither an absolute operating system path nor a browser URL. Administrators can use this path together with the approximate time of the request to locate the relevant diagnostic information. It identifies the log file relevant to the specific failure. For example, it may reference the common SCM log:
```
logs/common_logger.log
```
If the failure occurs during a Siebel deployment stage and a stage-specific diagnostic log is available, data.log_path may instead contain the corresponding safe, relative path to that log.
For example, if the SCM home directory on the server is /home/opc and the response contains:
```
{
    "data": {
        "log_path": "logs/common_logger.log"
    }
}
```
The administrator can review the corresponding log file on the server at:
```
/home/opc/logs/common_logger.log
```
The complete server path is used only when accessing and reviewing the log on the host. SCM does not expose the absolute file system path in the API response; the response contains only the safe, relative path.
When the SCM container fails to start. You can check the status of the SCM container and restart it as follows:
1. SSH in to the SCM instance.
2. Check the status of the SCM container:
```
sudo podman ps
```
  If this command does not return any output, it implies that the container hasn't started. In this case, check the cloud- init-output.log file:
```
vi /var/log/cloud-init-output.log
```
  If the log indicates that the container has failed or is not running, run the following command to confirm the status of the SCM container:
```
sudo systemctl status cloudmanager
```
  If the command output displays the container status as FAILED, restart the SCM container and check its status again as follows:
```
sudo systemctl restart cloudmanager
sudo systemctl status cloudmanager
```