Environment - SLES 12.3, latest patches, x86_64. VSEL 2.0.3, 6100 engine, Agent 5.6.6.
No on-demand scans running.
Scanner process starts as root with several children running as nails, as expected. After a short amount of time, another scanner process starts as root, and spikes a cpu core to 100%, and stays there until we kill it, turn off VSEL with \etc\init.d\nails stop, or reboot. Then later it creates another scanner running as root, and so on until the system is unresponsive.
I've written a cron job to monitor for more than one scanner process running as root, but I can't code well enough to make the script kill only the one that is NOT running correctly. E.g., the root scanner parent of the scanner processes running as nails are fine, so we only need to kill the one using 100% of a core while not spawning any children. Regardless of this script, when a core spikes to 100%, our system monitoring tools create an Incident in Service Now.
Meanwhile, there are 4,099 MFEdx log files in /var/log/. Not sure if this is related, but it's definitely annoying, and I haven't checked those log files yet because I wanted to get this forum post written.
What could be causing the additional scanner processes running as root? Is it the ma healthcheck cron job doing something?
Solved! Go to Solution.
The problem was resolved by updating Agent to 5.6.6 and verifying the VSEL Engine is at 6100, updating it if not.
We had some automation folks deploying Agent 5.0.5 because they thought it was newer than 5.5.0. I'm not sure why, nor do I understand the logic used, but the problem has been rectified.
Apparently the old Agent version was unable to communicate with and control VSEL properly on SUSE 12.3.
After reviewing the logs again today with a clear head, I discovered that the 6100 engine was downgraded to 5900 exactly 10 minutes after I upgraded it.
This is when the additional scanner as root process started and spiked to 100% for the cpu core it was using.
It appears that the DXL may have reverted the engine update after 10 minutes, inferring that the 10 minute logs where DXL tries to install itself each time is in the same time period.
The General Agent policy has the updates tab set to pull from the expected branch for the 6100 Linux engine.
Digging through logs to try to figure out why this happened.
Good day to you!
Could you please confirm if you are using the OS "SUSE Linux Enterprise Server 12 SP3"?
If yes, then the VSEL isn't supported on that OS yet. Additionally, the VSEL 2.0.3 has been announced EOL on 9/8/2020
You could consider upgrading to ENSLTP which is supported on the OS that you have mentioned.
Additionally, you do have the feature to limit the CPU utilized during an ODS.
ENSLTP Supported platform:
CPU Throttling for On-demand scan on ENS for Linux:
Let us know if you have any further queries.
With regards to the DXL issue that you have mentioned, please open a service request with the point product set as DXL or post the query on the DXL group for better assistance.
McAfee's page https://kc.mcafee.com/corporate/index?id=KB75270&page=content does not list any EOL for any of the 2.0.3 versions. It does list the release date of our VSEL 2.0.3 (with the 2635000 patch) as May 7th, 2020 though. So, you are telling me that you released it in May with plans to EOL it in 4 months without telling anyone?
But, considering it is not supported on SLES 12.3, McAfee won't support helping us. I can understand that from a business model. It is what we've come to expect from McAfee and we don't blame you for it. This is why I'm posting this on the community forum - I would like other users' input.
Does anyone else here (non-McAfee employee) know why the MFEdx logs are being created every 10 minutes when VSEL is running?
With regards to moving away from McAfee VSEL and to a different product - yes we are doing that, but it takes a while to migrate hundreds of thousands of servers supporting millions of customers, and we have to keep our current VSEL in place while we work to migrate everyone to our new solution. This involves troubleshooting our systems that are not ready for migration yet.
if see that VSEL was released in 2016 and other are hotfix which fix the vulnerability
|VSEL 2.0.3 (GA)||Release Notes||June 10, 2016|
why the MFEdx logs are being created every 10 minutes when VSEL is running?
it MFEdx agent which communicating to epo server generate this logs