Console not accessible after applying Linux OS Patches

Products

• Data Loss Prevention
• Data Loss Prevention API Detection
• Data Loss Prevention API Detection for Developer Apps Virtual Appliance
• Data Loss Prevention Cloud Detection Service
• Data Loss Prevention Cloud Detection Service for Endpoint
• Data Loss Prevention Cloud Detection Service for ICAP
• Data Loss Prevention Cloud Detection Service for REST
• Data Loss Prevention Cloud Package
• Data Loss Prevention Cloud Prevent for Microsoft Office 365
• Data Loss Prevention Cloud Service for Discovery/Connector
• Data Loss Prevention Cloud Service for Email
• Data Loss Prevention Cloud Storage
• Data Loss Prevention Core Package
• Data Loss Prevention Data Access Governance
• Data Loss Prevention Discover Suite
• Data Loss Prevention Endpoint Discover
• Data Loss Prevention Endpoint Prevent
• Data Loss Prevention Enforce
• Data Loss Prevention Enterprise Suite
• Data Loss Prevention for Mobile
• Data Loss Prevention Form Recognition
• Data Loss Prevention Network Discover
• Data Loss Prevention Network Monitor
• Data Loss Prevention Network Monitor and Prevent for Email
• Data Loss Prevention Network Monitor and Prevent for Email and Web
• Data Loss Prevention Network Monitor and Prevent for Web
• Data Loss Prevention Network Prevent for Email
• Data Loss Prevention Network Prevent for Email Virtual Appliance
• Data Loss Prevention Network Prevent for Web Virtual Appliance
• Data Loss Prevention Network Protect
• Data Loss Prevention Oracle Standard Edition 2
• Data Loss Prevention Plus Suite
• Data Loss Prevention Sensitive Image Recognition

Issue/Introduction

Linux OS Patches were applied to the DLP Enforce Server and after reboot of the server the Console is not accessible

Environment

RHEL 

Cause

The DLP Enforce server is unable to locate needed libraries, resulting in an unsatisfiedlinkerror:

The logs shared: 

INFO   | jvm 1    | 2025/11/14 20:43:28 | WrapperSimpleApp Error: Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.symantec.dlp.imagematching.imageutilities.jni.ImageUtilities]: Factory method 'imageUtilities' threw exception; nested exception is java.lang.UnsatisfiedLinkError: /opt/Symantec/DataLossPrevention/ServerPlatformCommon/<version>/Protect/lib/native/libImageUtilitiesJNI.so: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /opt/Symantec/DataLossPrevention/ServerPlatformCommon/<version>/Protect/lib/native/libopencv_imgcodecs.so.4.5)....

This led us to verify the installed files and dependencies: 

rpm -q libstdc++

and it returned: 

[root@SERVERNAME ld.so.conf.d]# rpm -q libstdc++

libstdc++-8.5.0-28.el8_10.x86_64

which was correct, we then ran: 

strings $(ldconfig -p | awk '/libstdc\+\+\.so\.6/ {print $4; exit}') | grep GLIBCXX_3.4.26

 

And it returned: 

[root@SERVERNAME ld.so.conf.d]# strings $(ldconfig -p | awk '/libstdc\+\+\.so\.6/ {print $4; exit}') | grep GLIBCXX_3.4.26

GLIBCXX_3.4.26

GLIBCXX_3.4.26

which is correct

Make sure to check the SymantecDLPManager.conf  file ( and all services conf files ) for the line set.LD_LIBRARY_PATH, make sure its looks like the following:

set.LD_LIBRARY_PATH = ../lib/native;../../../../ServerPlatformCommon/<version>/Protect/lib/native;%LD_LIBRARY_PATH%

If this is missing or commented out, it can cause the concern to occur as well. 

With the above verification confirmed, this led us to prioritize the DLP Libraries

Resolution

Prioritize the DLP Libraries by using the following command: 

export LD_LIBRARY_PATH=/opt/Symantec/DataLossPrevention/ServerPlatformCommon/<version>/Protect/lib/native:$LD_LIBRARY_PATH

( the above export command is all one line )

Once set we cycle all services on the DLP server and this allowed services to come back up.

It is also recommended to update the BASH for the DLP user as outlined in the following TechArticle: https://knowledge.broadcom.com/external/article/253465

**** A Special Note***** The BASH will need to be updated EVERYTIME the DLP Version is upgraded ( for example 16.1 to 25.1 ) as we specified the specific path for the currently installed version of DLP , as that changes, so must the bash change.

Also, you will need to make sure the Bash for the DLP Service Account is updated so DLP recognizes items

If for some reason the strings command does not provide an output, run the following and make sure the libstdc is not pointing to the OS version of the libstdc library.  Please make sure to update the version part in the path to match the version of DLP that is running.

ldd /opt/Symantec/DataLossPrevention/ServerPlatformCommon/<version>/Protect/lib/native/libImageUtilitiesJNI.so: /lib64/libstdc++.so.6

Output should look something like:

        libstdc++.so.6 => /opt/Symantec/DataLossPrevention/ServerPlatformCommon/<version>/Protect/lib/gnu/libstdc++.so.6 (0x00007f40832d1000)

If the above is point to a system library, you can look over the ldconfig settings and make sure these are correct under /etc/ld.so.config.d