--- title: "SKP Connector Troubleshooting" slug: "skp-connector-troubleshooting" updated: 2024-05-07T18:19:38Z published: 2024-05-07T18:19:38Z canonical: "skthelp.syniti.com/skp-connector-troubleshooting" --- > ## Documentation Index > Fetch the complete documentation index at: https://skthelp.syniti.com/llms.txt > Use this file to discover all available pages before exploring further. # SKP Connector Troubleshooting ## **Overview of Services** The Syniti Knowledge Platform Connector and Associated Services is a set of capabilities that allow for connectivity and targeted processing for key capabilities provided by the Syniti Knowledge Platform (“SKP”). The services deployed with the Syniti Connector are: ### SYNITI-RDC The Remote Data Connectivity or “RDC” service is the main service that provides connectivity from the remote Syniti Knowledge Platform Connector machine and SKP. This service provides the software-managed secure connectivity by polling out from the Syniti Knowledge Platform Connector machine back to SKP on a regular basis ensuring a live and healthy connection between the Syniti Connector machine and SKP. ### SYNITI-AGENT-REST RESTful web service running on the Syniti Knowledge Platform Connector that serves as the broker for scanning, profiling and replication engines. ### **Service Troubleshooting** The two primary services that run on the Syniti Knowledge Platform Connector machine are developed so as to use standard operating system level logging for their actions. If issues are thought to be with the services themselves, it is best to check the status of the services directly on the Syniti Knowledge Platform Connector machine: 1. Check to see if the services are running. 2. If the status of the service is not “active (running)” then try the following: 1. Restart the services using the restart commands in the below section. After restarting the services, check the status of the services. 2. Check the recent logs for the services to check for error message that can further the troubleshooting. If there are service issues it is recommended that troubleshooting start with the SYNITI-RDC service and then move to the SYNITI-AGENT-REST service. Both services are required for full SKP . ### Key Commands #### **SYNITI-RDC Service** This command provides a status of the SYNITI-RDC service and whether it is actively running or not. *sudo systemctl status syniti-rdc* ![](https://cdn.document360.io/ca09b4e9-1857-4c63-9f0e-1f25f166f447/Images/Documentation/image(310)(1).png?sv=2026-02-06&spr=https&st=2026-11-12T23%3A36%3A50Z&se=2026-11-13T00%3A36%3A50Z&sr=c&sp=r&sig=9uQehsKtWd%2BDF4K4owaekQyEEAZpeOEQB%2BKgoCTfHgg%3D)Figure 1 **Figure 1: Running Service** This command restarts the SYNITI-RDC service: *sudo systemctl restart syniti-rdc* If the service is not running or you would like more details about the service, you can check the full logs of the service using the following command: *sudo journalctl -u syniti-rdc* This command gives you the full logs of the service. Some helpful flags to send this command are described here. This command shows you all of the logs for the past 30 minutes. Notice the text in the quotes below can be changed to extend or shorten the timeframe of the logging. *sudo journalctl -u syniti-rdc --since "30 minutes ago"* The Syniti support team may request the copy and pasting of these log messages from your terminal session into a ticket. The `-f` in the command below follows the log live on the screen so that you can watch in real time the status and state of the service: *sudo journalctl -u syniti-rdc --since "30 minutes ago" -f* Logging of all packets over the connector using the Wireshark format can be enabled on the machine running the syniti-rdc service. In order to view the logs, it is recommended that Wireshark is installed on the machine running the service. To enable the Wireshark logging use the following command: *sudo systemctl enable --now syniti-packet-capture@wg0.service.* Running this command runs tcpdump and stores a cyclic buffer of packets transferred over the Wireguard interface in the following folder: */var/log/syniti-pcap* With Whireshark installed, the resulting logs can be viewed using the following command: *tshark -r .pcap -V* > [!NOTE] > **Note** > > The above logging is supported on SUSE and Ubuntu agents only at this time. Redhat logging is in development and this article will be updated when it is deployed. #### **SYNITI-AGENT-REST Service** This command provides a status of the SYNITI-AGENT-REST service and whether it is actively running or not. *sudo systemctl status syniti-agent-rest* ![](https://cdn.document360.io/ca09b4e9-1857-4c63-9f0e-1f25f166f447/Images/Documentation/troubleshooting2.png?sv=2026-02-06&spr=https&st=2026-11-12T23%3A36%3A50Z&se=2026-11-13T00%3A36%3A50Z&sr=c&sp=r&sig=9uQehsKtWd%2BDF4K4owaekQyEEAZpeOEQB%2BKgoCTfHgg%3D)Figure 2 Additional commands can be made to the web service itself to check for the health of the service. There is a defined Health endpoint that can be called with the following command: *curl http://localhost:9100/health -i* If this commands returns a 200 or “OK” message than the service is running correctly: ![](https://cdn.document360.io/ca09b4e9-1857-4c63-9f0e-1f25f166f447/Images/Documentation/troubleshooting3.png?sv=2026-02-06&spr=https&st=2026-11-12T23%3A36%3A50Z&se=2026-11-13T00%3A36%3A50Z&sr=c&sp=r&sig=9uQehsKtWd%2BDF4K4owaekQyEEAZpeOEQB%2BKgoCTfHgg%3D)Figure 3 ### **Connectivity Troubleshooting** #### **Connecting SQL Server to Java Metadata Scanner** You can correct the issue if you receive this message when attempting to connect a SQL Server instance to the Java metadata scanner: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: “The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]” > [!NOTE] > **Note** > > The Java 11 default configuration disables TLS1. > [!NOTE] > **Note** > > This task must be performed by a Linux administrator. To fix the issue: 1. Open the JVM file `conf/security/java.security.` 2. Search for the property `jdk.tls.disabledAlgorithms`. For OpenJDK 11, its contents are similar to: jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \ DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \ include jdk.disabled.namedCurves 3. Remove the TLSv1.1 and/or TLSv1 entries to re-establish those versions back to the list of usable versions within the JDK. > [!NOTE] > **Note** > > The administrator may also have to execute this command to enable older protocols in the operating system: > > ```plaintext > update-crypto-policies --set LEGACY > ``` #### **Syniti Knowledge Platform Connector Machine to External Customer Systems** One of the primary items to troubleshoot is the connectivity from the machine running the Syniti Knowledge Platform Connector and the external systems to which it needs to connect. What follows is troubleshooting steps for debugging Knowledge Platform Agent connectivity to external systems. #### **Replication Engine** This is the communication between the Syniti Knowledge Platform Connector machine and the Replication engine via web services. The recommended approach to check for connectivity is by using CURL commands from the Syniti Knowledge Platform Connector machine to the Replication engine. **Health Check** *curl http://:58380/health -i* Example: *curl http://10.1.1.1:58380/health -i* If this command returns a 200 or “OK” then the replication engine is running and reachable: ![](https://cdn.document360.io/ca09b4e9-1857-4c63-9f0e-1f25f166f447/Images/Documentation/troubleshooting4.png?sv=2026-02-06&spr=https&st=2026-11-12T23%3A36%3A50Z&se=2026-11-13T00%3A36%3A50Z&sr=c&sp=r&sig=9uQehsKtWd%2BDF4K4owaekQyEEAZpeOEQB%2BKgoCTfHgg%3D)Figure 4 **List Replications** For a more detailed test, a call can be made to list the replications registered against the engine using this command: http://**:58380/replications Example: *curl http://10.1.1.1:58380*:58380/replications If there are registrations registered, this command will return a payload in JSON format of the replications registered against the engine. If the Replication Engine is not connecting, please check the following : - The configured Ports in the Replication Engine are open for traffic between the Replication Engine and the Syniti Knowledge Platform Connector machine. ![](https://cdn.document360.io/ca09b4e9-1857-4c63-9f0e-1f25f166f447/Images/Documentation/troubleshooting5.png?sv=2026-02-06&spr=https&st=2026-11-12T23%3A36%3A50Z&se=2026-11-13T00%3A36%3A50Z&sr=c&sp=r&sig=9uQehsKtWd%2BDF4K4owaekQyEEAZpeOEQB%2BKgoCTfHgg%3D)Figure 5 - If ‘the Enable Agent HTTP SSL’ is set to True, use HTTPS type addresses when connecting to the test URLs. #### **Match API** The Match API is the communication between the Syniti Knowledge Platform Connector machine and the Match API via web services. To check for connectivity, use CURL commands from the Syniti Knowledge Platform Connector machine to the Match API. Use this Linux command: *sudo ss -lptn* The Match API (process “Cortex_WebService“) is listening to either the port 59000 or 59001, depending on whether you have used an authorized SSL certificate or not. Use the following CURL command to check that the service is working (changing the port if required): *curl -X GET http://10.4.1.66:59000/Cortex* An HTTP 200 OK return code should be produced, listing any instances of the service that have already been initialized. The remote Match API generates a log file here: */opt/syniti-match/service_log.txt* The service can be stopped and restarted using the code below, but note that any running jobs will be aborted if you run it: sudo systemctl stop syniti-match sudo systemctl start syniti-match Connectivity through to the Match API can also be tested from the Admin module in the Syniti Knowledge Platform. To test the connectivity: 1. Select **Admin** from the *Profile* menu. 2. Click **Match** in the *Admin* menu. 3. Click the **Remote Services** tab. 4. Click the **Test connection** button for the remote service to test. If the test connection is successful, the version information is set for the service, indicating the version of the Match API that is running on the remote machine. ### **Active Metadata Scanning** The active metadata scanning that executes in the Syniti Knowledge Platform Connector machine uses a Java-based engine to run and execute metadata scans. This engine can be run directly from the command line of the Knowledge Platform Agent machine to test for connectivity and execution. To test the scanning-based connectivity, first navigate to: *cd /opt/apps/syniti-scanners/* Once in that directory, run this command to test the connectivity of the scanners: *java -jar syniti-dispatcher-.jar -s -t schema -o test -c * *Example: java -jar syniti-dispatcher-1.2.0.jar -s sqlserver -t schema -o test -c "jdbc:*[*sqlserver://10.4.256.256:1433*](sqlserver://10.4.256.256:1433)*;user=myUserID;password=myPassword"* If the test passes successfully, this message displays: *{"error":"","result":{"passed":true}}* Other messages that could be returned would contain more detailed error messaging that can be used for additional troubleshooting. The Active Metadata Scanners log their progress and output to a dedicated folder on the executing machine. By default this folder is: */var/syniti-agent/scanner/logs* In this folder, for each scan, these kinds of log files are stored: - Technical Logs—Named with the prefix “tech_” and then the uniqueID of the scan, these logs contain the technical details of the scanner execution - Scanner Logs—Named for the uniqueID of a scan, these logs contain the details of the scanner execution - Test Connection Logs—These log files begin with `blank_requestid` and correspond to test connections being made by the scanner In the dispatcher’s `/opt/apps/syniti-agent/scanners/scan.properties.json` file, you can specify JVM arguments that will be passed when running a specific scanner. For example, if a scan fails due to an out-of-memory error you could increase the JVM’s memory allocation using: ```plaintext - “jvmArguments”: “-Xms5G -Xmx5G”. ``` ### **Adjust RFC_READ_TABLE ROWCOUNT** Administrators can adjust the RFC_READ_TABLE ROWCOUNT parameter by setting a JRE system property called rfc.rowCount. This property determines how many rows are read in each call to RFC_READ_TABLE for DD03L (SAP fields). The default value is 1000000. Adjusting the value to be greater than 1,000,000 will decrease runtime but increase user session memory in the SAP system. A simple way to set this property is to use the jvmArguments value in the scanner control file /opt/apps/syniti-agent/scanners/scan.properties.json, for example "jvmArguments": "-Drfc.rowCount=500000". ## Reconfigure SKP Connector Services ### **Change Regions and Connectivity from Development to Production Environments** If you must change the region (US, EU and AU) that the SKP Connector is communicating with or change connectivity between Dev and Prod environments, follow the steps in this section. There are two files that are updated as part of this process: - */lib/systemd/system/syniti-agent-service* - */etc/syniti-rdc/config.hcl* To reconfigure SKP Connector Services: 1. Run the following command to display the first file’s contents: *cat /lib/systemd/system/syniti-agent-rest.service* 2. Run the following command to allow you to edit the file: *sudo vi /lib/systemd/system/syniti-agent-rest.service* File Contents: [Unit] Description=Syniti Agent Service [Install] WantedBy=multi-user.target [Service] Type=simple ExecStart=/usr/bin/syniti-agent-rest -profile-data-dir "/var/syniti-agent/profiler" -scan-data-dir "/var/syniti-agent/scanner" -venv-path "/opt/apps/syniti-agent/profiler/.venv/" -status-url **"https://api.syniti-dev.com/agent/notify/status-update"** Restart=on-failure User=synitirdc 3. Edit the entry in bold above to point to the relevant production environment: **US Region—**https://api.syniti.**com**/agent/notify/status-update **EU Region—**https://api.syniti.**eu**/agent/notify/status-update **CA Region—**https://api.syniti.**ca**/agent/notify/status-update **AU Region—**https://api.syniti.**au**/agent/notify/status-update 4. Save the changes, and (press Escape WQ!) to save the file. 5. Run the following command to display the contents of the second file: *cat /etc/syniti-rdc/config.hcl* 6. Run the following command to allow you to edit the file: *sudo vi /etc/syniti-rdc/config.hcl* File Contents: # Syniti Remote Data Connection Agent Configuration remote { # Configuration server URL. This is the URL from which endpoint configuration # will be fetched according to poll_interval. # # Default: https://onprem.syniti.com/rdc/config url = **"https://onprem.syniti-dev.com/rdc/config"** # How often to poll the configuration server for updated configuration. # Expected to be in Go's duration format, e.g. "15m", "30s", "2h", etc. # # Default: 1m poll_interval = "1m" } # Interface to configure. # # Default: wg0 interface = "wg0" 7. Edit the entry in bold above to point to the relevant production environment: **US Region—**[https://onprem.syniti.com/rdc/config](https://api.syniti.com/agent/notify/statut-update) **EU Region—**[https://onprem.syniti.eu/rdc/config](https://api.syniti.com/agent/notify/statut-update) **AU Region—**[https://onprem.syniti.au/rdc/config](https://api.syniti.com/agent/notify/statut-update) 8. Save the changes, press Escape WQ! to save the file. 9. Run the following commands to restart the services: **To restart the daemon:** *sudo systemctl daemon-reload* **To stop the service:** *sudo systemctl stop syniti-agent-rest* **To start the service:** *sudo systemctl start syniti-agent-rest* **To stop the service:** *sudo systemctl stop syniti-rdc* **To start the service:** *sudo systemctl start syniti-rdc* > [!NOTE] > Note > > You can run a *sudo systemctl status* command on each of the services to check that they are running correctly.