GOAL
A patch was installed on a runtime instance as per article:
How to apply patches in Mule runtimes (standalone and in Studio). There is a requirement to validate if that patch is actually applied and loaded by the runtime process after a restart
PROCEDURE
Below are some methods to verify whether the patches are correctly applied to mule runtime.
Note: Mule 4.x uses lazy initialization to get a better performance. You may see some of the jars, patches are not loaded unless they are required by an app.
METHOD 1
Latest runtimes, e.g. 3.9.x and newer report all patches loaded at startup time in
MULE_HOME/logs/mule_ee.log file. For example:
**********************************************************************
* Mule Runtime and Integration Platform *
* Version: 3.9.2 Build: 495bc74d *
* MuleSoft, Inc. *
* For more information go to *
* http://www.mulesoft.com/mule-esb-enterprise *
* *
* Server started: 1/08/19 13:37 PM *
* JDK: 1.8.0_xxx (mixed mode) *
* OS: Mac OS X (10.14.6, x86_64) *
* Host: xxxxxxx-ltm.salesforce.com (10.xx.xx.xx) *
* Applied patches: *
* - SE-xxxxx-3.9.2-3.0.jar *
* - SE-xxxxx-3.9.2-1.0.jar *
* Mule system properties: *
* - mule.base = *
* ~/mule-enterprise-standalone-3.9.2 *
* - mule.home = *
* ~/mule-enterprise-standalone-3.9.2 *
**********************************************************************
NOTE
For Mule 3.x this method only works for patches that have the prefix 'SE-'. For some old versions of mule 4.x versions also you will see this method does not work. Please use Methods 2 below instead.
METHOD 2
To validate that your Dataweave patch was applied, please complete the readme.txt instructions that are included in the zip file you downloaded for the patch. After completing the readme instructions, restart your version of Studio and run any project. After the project deploys, look in the console and search for “data-mapper-plugin.” Under “data-mapper-plugin”, you should see the name of your patch if it was successfully installed. For example, if you installed the patch for “mule-ee-distribution-standalone-3.9.5-20210322-patch.jar” and you see the below in the console, it means your patch was successfully applied:
INFO 2021-05-18 14:40:14,159 [main] com.mulesoft.mule.plugin.manager.MulePluginManager: Registering plugin: mule-plugin-weave-3.9.5-20210322-dist
METHOD 3
This method involves checking if a runtime process holds a file descriptor to a patch open. Steps are based on the operating system vendor.
It can be used for patches with any file name convention, for example SE-1234.jar, SEC-98765.jar or MULE-22222.jar
Linux or macOS
- Identify runtime process ID. Either command can be used. Needs to be executed under the root or the same user used to execute Mule Runtime.
- Using Java jps (Java Process Status Tool) command line tool to find the process ID. The process will be called MuleContainerBootstrap if is a standalone runtime, or ApplicationDeployer if it is running in Studio. Example:
-
$ jps
31077 Jps
30636 MuleContainerBootstrap
- Using ps -ef:
$ ps -ef |grep java |grep mule.home
ion-mule 30636 30634 17 04:45 ? 00:01:32 /etc/jdk8/bin/java -Dmule.home=/opt/mule/mule-4.2.0
- Check if lsof (list open files) shows the patch file in the output. For example for a patch named SE-1234.jar:
$ lsof -p 30636 | grep "SE-1234.jar"
Note, several filters separated by pipe "|" inside the quoted search expression can be used with grep, e.g.: grep -E "SE-1234.jar|SE-5678.jar"
This confirms the patch is loaded by a runtime:
java 30636 xxxxxx xxxx xxx xxx xxxxxxxx /path/to/patch/applied/SE-1234.jar
IBM AIX or UNIX
The process of identifying files opened by a process in IBM AIX is described
here.
- Identify process ID similar to the "Linux of macOS", step 1
- Identify inode of the patch file:
ls -i SE-XXXX.jar
the output may look like:
7368 SE-XXXX.jar
- Check if the inode is opened for a runtime process ID:
lsof -p RUNTIME_PID | grep 7368
The output should look similar to:
java RUNTIME_PID mulesoft 91r VREG 45,2 2224 7638 /opt (/dev/hd00)
If you see the output, a file descriptor to a patch file is open and patch is loaded.
Note, on the left from inode, a file size in bytes, e.g. 2224, may be observed. This can be used to additionally ensure the open file descriptor corresponds to a patch file. - Alternatively to step 3, instead of lsof -p RUNTIME_PID, procfiles RUNTIME_PID can be used.
Microsoft Windows
- Identify runtime process ID. Either approach can be used. Ensure Command Prompt is run as administrator (Click "Start -> type "cmd" -> right mouse click on "Command Prompt" -> choose "Run as administrator")
- Ensure the JDK bin folder is added to %PATH% variable. and execute jps (Java Process Status Tool) command:
- Execute tasklist /svc command:
C:\Users\Administrator\Desktop\Handle>tasklist /svc |findstr java
java.exe 1752 N/A
C:\Users\Administrator\Desktop\Handle>
- Using Task Manager after adding PID column to Processes tab:
- Using WIndows PowerShell run as administrator:
PS C:\mule\mule-enterprise-standalone-4.1.4> gwmi Win32_Process -Filter "name='java'"
- Download and install handle64.exe utility from Microsoft Sysinternals website.
- Execute handle64.exe as below. You need to first execute the following command, and accept the terms and conditions to use the software.
c:\handle64 -p 1752
After accepting the prompt on terms and conditions, you can filter the output with 'findstr' as shown in the next step. - Several search patterns separated by space can be used:
c:\handle64 -p 1752 | findstr "SE-XXXX SE-YYYY"
the output should look like:
xxx File /path/to/patch/applied/SE-XXXX.jar
xxx File /path/to/patch/applied/SE-YYYY.jar
- A sample output using gwmi and handle64 is shown below:
