Possible Root Cause
Obtain a diagnostic package of the Linux Deep Security Agent. Open the proc-dsa-configs file and check the numerical values in the file:
count = 10
max = 10
limit = 10
If all the values are "10", the agent already has the maximum number of active configurations that it can handle. Count refers to the current active configuration count. Max is the highest value that count has ever equaled since the Agent started. Limit is the most active configurations that can be uploaded. When count and limit both have "10" as their value, it means that the Agent will no longer be able to update.
The reason we have to be able to load multiple configurations in memory can be complex, but the basic principle is that because there is constant network activity on a machine. We need to ensure that the security configuration does not get modified when we are in the middle of processing a packet.
For example, if we are processing packet A and we switched the configuration in the middle of it, then we may not get the full protection needed and packet A could go through without being properly inspected.
To avoid this, when the driver is processing one or more packets when a new configuration is being pushed down, then it will not replace the active configuration. It will simply load a second configuration into the memory and the first configuration will remain active until the processing of these packets is completed.
Recommended Solution/Workaround
Normally, the active configuration should be somewhere between 2 or 3
Restarting the ds_agent and ds_filter processes will clear all configurations from memory and start over, which should allow the Agent to update.
- Check if the ds_filter driver can be reloaded successfully using these commands:
# /etc/init.d/ds_agent stop
# /etc/init.d/ds_filter stop - If the commands work, then everything will be cleared out when you start up the ds_filter driver using these commands:
# /etc/init.d/ds_agent start
# cat /proc/driver/dsa/info - Clear all the Warnings/Error on the Deep Security Agent. Try and update the Deep Security Agent to the latest configuration.
Further Troubleshooting
If the above steps fixed the problem, collect another Diagnostic Package after a day or two to verify that the count stays between 2 or 3. Otherwise, collect the same Diagnostic Package and send to Trend Micro Technical Support for analysis.
Possible Root Cause
The old driver was not unloaded during uninstall, which means that the new driver could not be loaded and the old driver is still running.
It failed to unload because something is still holding on to it. Obtain a diagnostic package of the Linux Deep Security Agent. Open the dsa-state-capture-output.txt file and see if you can see these lines:
### LSMOD
Module Size Used by
dsa_filter 673720 2
This means that there are two things that are holding on to it: one is the ds_agent usermode process and the other is not yet identified.
Recommended Solution/Workaround
- Try to manually stop the agent and old driver.
# /etc/init.d/ds_agent stop
# /etc/init.d/ds_filter stop - If it works, then it should load the new driver when you start it up again.
# /etc/init.d/ds_agent start
# cat /proc/driver/dsa/info - If that does not work, you can check /var/log/messages to see if there is any more information on why it does not load. However, the most effective way to remove a driver is to do a reboot as it will clear the old and load the new one.
The most careful way to do it is to follow these steps:
- Run these commands to uninstall the Deep Security Agent:
# rpm -e ds_agent
# reboot - After the reboot, run this command:
# lsmod | grep dsa_filter
This checks that the dsa_filter is no longer loaded. You should not see "dsa_filter" in the list.
- Install the Deep Security Agent.
# rpm -ivh Agent-RedHat_2.6.9_34.EL_x86_64-6.1.0-34.x86_64.rpm
- Check and make sure that the latest driver is not loaded successfully.
# cat /proc/driver/dsa/info