DLP Detection Server Controller service not able to start up within 30 seconds after being started

Products

• Data Loss Prevention Core Package

Issue/Introduction

The Symantec DLP Detection Server Controller service on Enforce is not able to stay in a Running state, and instead stops after approximately 30 seconds since its startup. 

In addition, you may see an accumulation of .bad files in the incidents folder on Enforce. Because Detection Server Controller is down, incident queue will be growing on the detection servers. 

Cause

In the MonitorController.log logs, the following exception will appear during the process startup:

java.lang.NullPointerException at com.vontu.util.filesystem.monitoring.FileCleaner.processAll(FileCleaner.java:57)
at com.vontu.util.filesystem.monitoring.FolderCleanupTask.deleteAllFiles(FolderCleanupTask.java)

The exception is thrown at the startup stage where Detection Server Controller attempts to start the IncidentWriter subservice. You may also see other exceptions in the logs, reporting problems with listing of files in the incidents folder or access issues to the directory. 

Resolution

Recreation of the D:/ProgramData/Symantec/DataLossPrevention/ServerPlatformCommon/<version>/incidents folder might be required - as the original folder might be i.e. corrupted or have any disk-level problem. 

Make sure that the newly created folder has the required read/write access granted to the DLP service account, as this will be the account writing the .idc files into the folder.

Then, once the folder is created, edit the below parameter in Protect.properties to point at the new incidents folder:

com.vontu.manager.incidents.dir

Restart the DLP services. After the restart, you should see .idc files being written into the new incidents folder and Detection Server Controller should be able to stay in Running state. 

At a later stage, you can attempt to delete or rename the corrupted old incidents folder, and rename the new folder back into 'incidents' and reconfigure the com.vontu.manager.incidents.dir back to the default path. This will ensure that the original name and path of the incidents folder is used again, while the folder itself is the new non-corrupted folder created to fix the problem.

For any .bad files that have been generated please see the following KB to correct them.

Changing all .bad incidents to .idc on a Windows operating system