Troubleshoot Cortex XSOAR Engines
Troubleshoot engines in Cortex XSOAR 6.12.
When troubleshooting Cortex XSOAR engines, access the logs from Settings → Integrations → Engines and select the engine from which you want to download the logs.
Debug Engines
The d1.log field appears whenever a Cortex XSOAR engine is running. The d1.log field contains information necessary for your customer success team to debug any engine related issue. The field displays any error, as well as noting whether the engine is connected.

If you encounter issues when connecting to an engine, follow these procedures:
Troubleshoot Engine Installation
After installing the engine, check that the XSOAR engine is connected to the main server and that it is running.
Go to Settings → INTEGRATIONS → Engines and verify that the engine is connected.

engines-troubleshooting-connected.png If the engine is not connected, run the following command on the engine server to check if the engine service is running.
sudo systemctl status d1Access the d1 log on the engine server.
sudo tail -f /var/log/demisto/d1.logIf the engine service wasn’t running, and there’s nothing relevant in the log, run
journalctlon the engine server to understand why the installation failed.If the engine service is running, review the errors to see if the engine is failing to connect or if there are other issues. (Ignore all errors related to \d2ws, since this is not the same as d1ws.) Most often, the server address is incorrect and you will see an error like this:
error Cannot connect to [wss://<mainServerIP/HostName>/d1ws]: wss://<mainServerIP/HostName>/d1ws: dial tcp: lookup localhost: no such host. . Waiting 3 seconds. Will try until…In this case, navigate to
/usr/local/demisto/d1.confand change the EngineURLs parameter to an address the engine can reach. Check the addresses at the beginning of the upgrade_engine.sh file and update them to be the same as in the conf file. The addresses should be a comma-separated list.The configurations that might affect the upgrade_engine.sh script are the following variables located at the beginning of the script:
SERVER_URLSTRUST_ANY_CERT
If you make a change to the baseURLs configuration, you must apply the change in
/usr/local/demisto/d1.confAND in/usr/local/demisto/upgrade_engine.shunder the SERVER_URLS var.If you make a change in the
engine.connection.trust_any_certificateconfiguration, you must apply the change in/usr/local/demisto/upgrade_engine.shas follows:If the
engine.connection.trust_any_certificateconfiguration was set to true (trust any certificate), set the TRUST_ANY_CERT variable to -k.If the
engine.connection.trust_any_certificateconfiguration was set to false, the TRUST_ANY_CERT variable should be blank (““).
To check the connectivity from the engine to the main server, see Troubleshoot Engine Connectivity.
If the installation issue remains, open a support case with logs from the main server and engine.
On the engine server, in
/usr/local/demisto/d1.conf, set "LogLevel": "debug”.On the main server, navigate to Settings → ABOUT → Troubleshooting and verify that the Log Level is set to Debug.
Restart the d1 service and let it run for a few minutes.
sudo systemctl restart d1On the main server, go to Settings → ABOUT → Troubleshooting → Download logs to download a log bundle.
Capture a journalctl:
journalctl --since "1 day ago" > engineTroubleshootingJournalctl.logOn the engine server, tar up the logs, conf, journalctl, and install log on the engine.
tar -cvzf engineLogs.tar.gz /var/log/demisto /usr/local/demisto/d1.conf /tmp/demisto_install.log engineTroubleshootingJournalctl.log
Troubleshoot Engine Upgrades
During an upgrade, the upgrade file is sent to the engine server. A cron job running on the engine server checks if that file exists. The most common upgrade error is that the job is not running so the new installer does not run.
SSH to the machine.
Check the d1 service status on the engine server. It is possible that it stopped or doesn't exist.
sudo systemctl status d1Access the installer log on the engine server and review the error.
sudo vi /tmp/demisto_install.logRerun the installer on the engine server using one of the following options. You can open a second window and run
watch df -h. If the problem seems to be disk space, you should resolve the disk space issue and then rerun the installer.Option 1
Download the installer from the user interface and copy it to the engine server.
sudo chmod +x installer.sh
sudo ./installer.sh -- -y
Option 2
Verify that
/usr/local/demisto/d1_upgrade.shexists.If the file exists, run the following on the engine server:
sudo chmod +x /usr/local/demisto/d1_upgrade.shsudo /usr/local/demisto/d1_upgrade.shIf
d1_upgrade.shdoes not exist, check if/usr/local/demisto/archived_d1_upgrade.shexists and that it was created at the time of the attempted upgrade.If the file exists and was created at the time of the attempted upgrade, run the following on the engine server:
sudo chmod +x /usr/local/demisto/archived_d1_upgrade.shsudo /usr/local/demisto/archived_d1_upgrade.sh
Troubleshoot Engine Connectivity
The following provides instructions for troubleshooting connectivity issues from the engine to the endpoint.
Follow the instructions in network troubleshooting.
Ensure that the engine can reach the endpoint by running the following command on the server engine.
sudo curl -kvv <endpointURL>If the engine could not reach the endpoint, try the IP with curl instruction adding the http(s)//, or try using ping.
If this works, add the IP to the /etc/hosts file with the hostname and try to reach the endpoint again by running the following command on the engine server
sudo curl -kvv <endpointURL>.If this still fails, then this is an issue of connectivity between the engine and endpoint and you need to resolve this with your networking team.
Once connectivity has been confirmed via curl:
Try connecting within Docker without passing host networking.
docker run -it --rm demisto/netutils:1.0.0.6138 curl -kvv <endpointURL>If this succeeds but the integration still fails, it could be a integration credentials issue. In that case, open a support case.
If without passing host networking fails, run the following:
docker run -it --rm --network=host demisto/netutils:1.0.0.6138 curl -kvv <endpointURL>If this succeeds, add "python.pass.extra.keys": "--network=host" to /usr/local/demisto/d1.conf and retest the integration.
If you see a Docker or Selinux issue, see Troubleshoot Docker Networking Issues.
If the installation issue remains, open a support case with logs from the main server and engine.
On the engine server, in
/usr/local/demisto/d1.conf, set "LogLevel": "debug”.On the main server, navigate to Settings → ABOUT → Troubleshooting and verify that the Log Level is set to Debug.
Restart the d1 service and let it run for a few minutes.
sudo systemctl restart d1On the main server, go to Settings → ABOUT → Troubleshooting+Download logsto download a log bundle.
Capture a journalctl:
journalctl --since "1 day ago" > engineTroubleshootingJournalctl.logOn the engine server, tar up the logs, conf, journalctl, and install log on the engine.
tar -cvzf engineLogs.tar.gz /var/log/demisto /usr/local/demisto/d1.conf /tmp/demisto_install.log engineTroubleshootingJournalctl.log
Engine 443 Error
This error might occur when a connection is established between an engine and the Cortex XSOAR server, because, by default, Linux does not allow processes to listen on low-level ports.
Error Message
listen tcp :443: bind: permission denied
Solution
In the
d1.conffile, change the port number to a higher one, for example, 8443.Run this command:
sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary. After running this command the server should be able to bind to low-numbered ports.
Troubleshoot Integrations Running on Engines
The following are common errors that occur when integrations are running on an engine:
Troubleshoot Engine Import Error or Invalid Syntax Error
When running an integration on an engine, the most common errors are:
Broken PipeImportError: No module named...Invalid syntaxScript failed to run: exec: “python”: executable file not found in $PATH (2603)
These errors could indicate that the engine is not using Docker.
Use SSH to access the engine server.
Make sure Docker is healthy.
Ensure that Docker is installed and is running.
sudo systemctl status dockerIf the Docker status is not good, restart your Docker.
sudo systemctl restart dockerEnsure Docker can run a container.
sudo docker run hello-worldIf this fails, reinstall your Docker.
Access the d1.conf file on the engine server.
sudo vi /usr/local/demisto/d1.confAdd the
"python.engine.docker": trueconfiguration to the d1.conf file and remove any other configurations related to python and Docker, such as “python.executable.no.docker”.Restart the system on the engine server.
sudo systemctl restart d1Retest the integration from the user interface. This may take a few minutes since it may need to pull the relevant Docker image.
Troubleshoot Permission Denied
A common error message you may see when running integrations on engines is: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.35/images/json?t.
Determine if you are using a Docker group or Dockerroot group by running one of the following on the server engine:
ls -la /var/run/docker.sockThe output from this command will show what user/group is running docker.sock. For example:
shows that it’s a Docker group and not Dockerroot.
cat /etc/group | grep dockerThis command shows if you are running Docker or Dockerroot.
To fix a Docker user, run the following commands on the server engine:
sudo groupadd dockersudo usermod -aG docker demistosudo systemctl restart dockersudo systemctl restart d1
To fix a Dockerroot user, run the following commands on the server engine:
sudo groupadd dockerrootSet the dockerroot group in
/etc/docker/daemon.json. For example: { "group": "dockerroot" }.sudo usermod -aG dockerroot demistosudo chcon -Rt svirt_sandbox_file_t /var/lib/demisto/tempsudo systemctl restart dockersudo systemctl restart d1
Last updated
Was this helpful?
