Mue_InUse process becomes unresponsive on Linux/macOS/MLOS systems, consuming 100% CPU
Technical Articles ID:
KB95203
Last Modified: 2023-03-31 11:59:26 Etc/GMT
Environment
Advanced Threat Defense (ATD) 4.x
Data Exchange Layer (DXL) 6.x, 5.x
Endpoint Security for Linux Threat Prevention 10.7.x, 10.6.x
Endpoint Security for Mac Threat Prevention 10.7.x, 10.6.x
Threat Intelligence Exchange (TIE) Server 4.x, 3.x, 2.x
Trellix Agent 5.x
Supported Linux/macOS/MLOS systems operating systems
AMCore v3 content version 4683
Problem
1
You observe the following on your Linux system:
- The Mue_InUse process becomes unresponsive.
- The process eventually consumes 100% CPU.
You see the errors below in the McScript.log file ( /Var/McAfee/agent/logs/):
[ScrptExe] [E] [Executing section ExecuteDetectionScript]->
[ScrptExe] [E] [Line 626: RunScript dwRet = /var/McAfee/agent/update/Current/AMCORDAT2000/amcore.mcs, ScriptMain]->
[CmdPrsr] [E] Parse error line 350 column 36: Unexpected empty value
[CmdPrsr] [E] Error trace:
[Log] [E] [Main thread]->
[SessMgr] [E] [SessionManager::runScript:/var/McAfee/agent/update/UpdateMain.McS]->
[ScrptExe] [E] [Executing section ScriptMain]->
[ScrptExe] [E] [CallIf]->
[ScrptExe] [E] [Executing section StartUpdateProcess]->
You see the Mue_InUse process in an unresponsive state. You need to end the process to restore its function. The CPU is approaching 100%:
Problem
2
The MEDDAT content update fails on your macOS system:
You see the errors below in the McScript.log file ( /var/McAfee/agent/logs/):
[ScrptExe] [E] [Line 626: RunScript dwRet = /var/McAfee/agent/update/Current/AMCORDAT2000/amcore.mcs, ScriptMain]->
[CmdPrsr] [E] Parse error line 350 column 36: Unexpected empty value
[CmdPrsr] [E] Error trace:
[Log] [E] [Main thread]->
[SessMgr] [E] [SessionManager::runScript:/var/McAfee/agent/update/UpdateMain.McS]->
[ScrptExe] [E] [Executing section ScriptMain]->
[ScrptExe] [E] [CallIf]->
[ScrptExe] [E] [Executing section StartUpdateProcess]->
[ScrptExe] [E] [Call]->
[ScrptExe] [E] [Executing section DetectInstalledProductsAndUpdate]->
[ScrptExe] [E] [Call]->
[ScrptExe] [E] [Executing section GetDetectionScripts]->
[ScrptExe] [E] [Call]->
[ScrptExe] [E] [Executing section FindAndExecuteDetectionScripts]->
[ScrptExe] [E] [LoopIf]->
[ScrptExe] [E] [Executing section EnumerateThroughProductIDList]->
[ScrptExe] [E] [LoopIf]->
[ScrptExe] [E] [Executing section EnumerateThroughFile]->
[ScrptExe] [E] [Call]->
[ScrptExe] [E] [Executing section ExecuteDetectionScript]->
[ScrptExe] [E] [Line 626: RunScript dwRet = /var/McAfee/agent/update/Current/AMCORDAT2000/amcore.mcs, ScriptMain]->
[CmdPrsr] [E] Parse error line 350 column 36: Unexpected empty value
[CmdPrsr] [E] Error trace:
Problem
3
While the system is logging the Parse error line 350 column 36: Unexpected empty value error, it might also cause McScript.log to consume more disk space than what's configured in the Agent policy. The process doesn't perform the log rotate command and consumes disk space until the system is rebooted or the Mue_InUse process is terminated.
Cause
The symptoms stem from production changes made in the AMCore content package, where the Extra.DAT deployment script ( extradat.mcs) is updated to include non-Windows platform support.
Even though Linux and macOS systems don't use AMCore content, the way the updates are deployed shows that the Agent executes the content update script for AMCORDAT2000 on these platforms. A difference in behavior between Windows and non-Windows platforms when parsing the script leads to an error for non-Windows systems only. The Script Engine behavior in this scenario is to retry running the script. This behavior creates a logic loop causing the high CPU consumption symptom of the Mue_InUse process.
Solution
This issue is resolved in AMCore content version 4684.
IMPORTANT:
- The 4684 content version doesn't terminate any Mue_InUse sessions that might still be running.
- The 4684 content version stops the errors seen in this article on any created tasks that have AMCore content selected in an update task.
NOTE: By design, the Mue_InUse process has the sigkill command hardcoded, and self-terminates after six hours. So, you might decide to wait for the Mue_InUse process to become terminated.
Configure the update task to install only the MEDDAT component and, if used, Endpoint Security Exploit Prevention Linux Content.
Actions at the ePO console:
- Log on to the ePO console.
- Select the respective group where the system is reporting.
- Click Assigned Client tasks, and edit the Product Update tasks.
- Deselect the AMCORE option for systems with Linux/macOS/MLOS operating systems in the group.
- Save the task.
- To apply the changes, send the wakeup call to all systems.
IMPORTANT: Disable all content update tasks that are enabled from the ePO console. Keep these tasks disabled until after the content has been updated ( AMCore version 4684), and the Mue_InUse process issue has been mitigated.
Workaround
1
End the Mue_Inuse process on the client.
Actions on the problem Linux/macOS/MLOS system:
- Connect to the problem system using SSH with the root user.
- To determine the processes running on the system, run the top command:
-bash-4.1# top
Output
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3559 root 20 0 538m 411m 9240 R 85.6 5.2 1 17:08.57 Mue_InUse
- Run the command below to end the existing Mue_Inuse process in the non-responsive state:
sudo pkill -f Mue_InUse
IMPORTANT: If the pkill command fails to end the process, type the following:
kill -9 <PID number of Mue_Inuse>
Example: kill -9 3559
- If you have multiple instances of the Mue_InUse processes, type the following:
killall -9 Mue_InUse
NOTE: The above command closes all Mue_InUse processes in one action.
Optional script solution:
An .sh script is attached to this article to use manually with a root user.
- Download the file killMue.zip in the "Attachment" section of this article.
- Extract the contents to a folder.
- Copy the killMue.sh to the problem system.
- Connect to the system via SSH.
- Navigate to the folder where you copied the .sh file.
Example: File copied to /tmp/
- Type the command:
[root@SGPRGC109002 tmp]# ls -ll /tmp/
Output:
total 41744
-rwxr-xr-x. 1 root root 90 Jan 19 17:29 killMue.sh
- To run the .sh file, you have to first assign the permission to the file before you can execute. If you don't assign the permission, you get the error below:
[root@SGPRGC109002 ~]# cd /tmp/
[root@SGPRGC109002 tmp]# ./killMue.sh
-bash: ./killMue.sh: Permission denied
NOTE: By default, the file doesn't have execute permissions.
[root@SGPRGC109002 tmp]# ls -ll /tmp/
Output:
total 41744
-rw-r--r--. 1 root root 90 Jan 19 17:29 killMue.sh
- Assign the execute permissions:
[root@SGPRGC109002 tmp]# chmod +x /tmp/killMue.sh
[root@SGPRGC109002 tmp]# ./killMue.sh
[root@SGPRGC109002 tmp]#
- To automate this procedure, use a third-party tool.
Workaround
2
If a single instance of the Mue_InUse process is found, follow the steps below:
- Disable all content update tasks that are enabled from the ePO console.
- Update to the new content in the ePO Main Repository: V2 DAT [10232], MEDDAT [4855], and V3 DAT [4684.0].
- Enable all Linux content update tasks.
- Push product update tasks to update the new content to all client systems.
NOTE: By design, the Mue_InUse process has the sigkill command hardcoded, and self-terminates after six hours. Hence, you might wait for the Mue_InUse process to get terminated.
Workaround
3
If you have multiple Linux systems affected, the RemoteKillMue tool can allow you to remotely kill the Mue_InUse process from a Windows system. Download the RemoteKillMue.zip file in the "Attachment" section of this article. Follow the instructions in the included Readme.txt file.
NOTE: The tool requires that the remote systems all have SSH enabled, that root logon for SSH is permitted, and that they all share a root password.
Workaround
4
To determine whether McScript.log files and associated backups are consuming the space after the Mue_InUse process has been terminated, run the following command. The command lists Agent log files and their respective sizes:
ls -lh /var/McAfee/Agent/logs
If the files are larger than what has been defined in the Agent policy, you can remove the files and restart the Agent service or restart the system.
Example command to remove the current McScript.log file:
NOTE: You must have root access to perform these actions. On MLOS systems (TIE or DXL), the service account might not be able to delete the files.
For Linux:
sudo rm -rf /var/McAfee/agent/logs/McScript.log
For MLOS:
[mcafee@mcafee~]#su
Password:
bash-4.1# rm -rf /var/McAfee/agent/logs/McScript.log
NOTE: Enter the root password when prompted.
See the following articles for Agent service commands:
Workaround
5
ATD
Root privilege is restricted on ATD. So, to address the symptoms on ATD you have two options:
- Apply an installable package.
- Open a Service Request, and request for a remote session.
IMPORTANT: Make sure to update the Product Update task in ePO per the "Solution" section, after completing either of the above options.
Applying an installable package:
Find a package in the "Attachment" section of this article, which terminates the spinning Mue_InUse process, and delete the logs.
- Download the atdpatch_MueInuse.zip, and extract the file atdpatch_MueInuse.msu.
- Upload atdpatch_MueInuse.msu (in .msu format) to ATD using the atdadmin account.
- Log on to command line interface using the cliadmin account, and execute the command below:
install msu atdpatch_MueInuse.msu
- On execution, you might see some errors similar to the ones below.
Error: job pid is not running: 2761
Error: Software Installation failed
You can safely ignore the errors. The file atdpatch_MueInuse.msu has a special format. Unlike regular update packages, where the command line interface only monitors the installation progress of regular upgrade package:
NOTE: It finishes within 30 seconds.
- Go to Manage, Logs, System in the ATD interface.
- Confirm that the log entries below are present. These logs indicate that the package is applied successfully.
Thu Jan 27 14:06:49 IST 2022::Installing software...
Thu Jan 27 14:06:49 IST 2022::Completed software installation, please reboot the system
- Manually restart the ATD from the command-line interface using the reboot command.
ATD runs normally after the reboot. Monitor the CPU use and scanning job progress in the ATD GUI.
Open a Service Request and request for a remote session
A Technical Support Engineer can take control over a remote session, and terminate the offending Mue_InUse process, or delete the large log files.
If you experience either high CPU consumption, or high disk space usage, open a Service Request. Include this article number and request a remote session.
- If you are a registered user, type your User ID and Password, and then click Log In.
- If you are not a registered user, click Register and complete the fields. Your password and instructions are emailed to you.
|
