One of the most common issues Oracle DBAs face during patching is the “CheckActiveFilesAndExecutables failed” error. This error occurs when Oracle’s OPatch detects that some files within $ORACLE_HOME are still in use by active processes.
When this happens, OPatch refuses to proceed to prevent corruption of binaries in use.
Here’s how you can diagnose and fix this issue safely using process-level checks.
Understanding the Error
When you try to apply a patch, the log may display something like:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.47
Copyright (c) 2025, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/product/19.0.0/dbhome_1
Central Inventory : /u01/app/oraInventory
from : /u01/app/oracle/product/19.0.0/dbhome_1/oraInst.loc
OPatch version : 12.2.0.1.47
OUI version : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2025-10-15_18-48-18PM_1.log
Verifying environment and performing prerequisite checks...
Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:
Following active files/executables/libs are used by ORACLE_HOME :/u01/app/oracle/product/19.0.0/dbhome_1
/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle
/u01/app/oracle/product/19.0.0/dbhome_1/lib/libclntsh.so.19.1
/u01/app/oracle/product/19.0.0/dbhome_1/lib/libasmclntsh19.so
/u01/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr
UtilSession failed: Prerequisite check "CheckActiveFilesAndExecutables" failed.
Log file location: /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2025-10-15_18-48-18PM_1.log
OPatch failed with error code 73
This message clearly shows which executables or libraries are still active under your $ORACLE_HOME.
The most common files reported are:
libclntsh.so→ Oracle client librarylibsqlplus.so→ SQL*Plus binaryoracleortnslsnr→ Database or Listener binaries
These files are in use by a process, and you need to identify and stop those processes before reapplying the patch.
Step 1: Review the OPatch Log File to Identify Active Files
Before running any commands, start by checking the OPatch log file that was generated during the failed patch attempt.
This log file provides detailed information about which executables, libraries, or binaries inside $ORACLE_HOME are still active and preventing the patch from proceeding.
You can find the log file location in the OPatch output. For example:
Log file location: /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2025-10-15_18-48-18PM_1.log
Open the log file and look for entries similar to:
[Oct 15, 2025 6:56:23 PM] [INFO] Following active files/executables/libs are used by ORACLE_HOME :/u01/app/oracle/product/19.0.0/dbhome_1
/u01/app/oracle/product/19.0.0/dbhome_1/lib/libclntsh.so.19.1
/u01/app/oracle/product/19.0.0/dbhome_1/lib/libasmclntsh19.so
/u01/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr
These paths identify which Oracle binaries are currently locked.
Make a note of each path — you’ll use them in the next step to find which process is holding the file open.
Step 2: Identify Which Processes Are Using the Active Files
Use the fuser command to find out which process IDs (PIDs) are holding locks on the executables mentioned in the OPatch error.
Example:
/sbin/fuser /u01/app/oracle/product/19.0.0/dbhome_1/lib/libclntsh.so.19.1
Output:
/u01/app/oracle/product/19.0.0/dbhome_1/lib/libclntsh.so.19.1: 2776m
This output shows two process IDs – 2776 – currently using the file.
Let’s now find what these processes are.
Step 3: Check Which Processes These PIDs Belong To
Use ps -ef | grep to get process details.
ps -ef | grep 2776
Output
$ ps -ef | grep 2776
oracle 2776 1 0 17:47 ? 00:00:00 /u01/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr LISTENER -inherit
oracle 10495 4463 0 19:08 pts/1 00:00:00 grep --color=auto 2776
Here, the process ID 2776 belongs to the TNS Listener.
Step 4: Kill the Active Processes
Once you confirm which processes are locking the binaries, terminate them using the kill command.
kill -9 2776 This kills both the listener and the SQL*Plus session that were keeping Oracle binaries in use.
If you see additional libraries reported (for example, libsqlplus.so), repeat the check:
/sbin/fuser /u01/app/oracle/product/19.0.0/dbhome_1/lib/libasmclntsh19.so
If this shows any active process IDs, kill those as well.
Step 5: Re-run OPatch Apply
Once all Oracle processes are stopped and binaries are released, reapply the patch:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/opatch apply
You should now see all prerequisite checks pass successfully:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.47
Copyright (c) 2025, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/product/19.0.0/dbhome_1
Central Inventory : /u01/app/oraInventory
from : /u01/app/oracle/product/19.0.0/dbhome_1/oraInst.loc
OPatch version : 12.2.0.1.47
OUI version : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2025-10-15_18-55-02PM_1.log
Verifying environment and performing prerequisite checks...
--------------------------------------------------------------------------------
Start OOP by Prereq process.
Launch OOP...
Oracle Interim Patch Installer version 12.2.0.1.47
Copyright (c) 2025, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/product/19.0.0/dbhome_1
Central Inventory : /u01/app/oraInventory
from : /u01/app/oracle/product/19.0.0/dbhome_1/oraInst.loc
OPatch version : 12.2.0.1.47
OUI version : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2025-10-15_18-56-36PM_1.log
Verifying environment and performing prerequisite checks...
OPatch continues with these patches: 37960098
Do you want to proceed? [y|n]
Why This Happens
The error occurs because Oracle OPatch must modify files within $ORACLE_HOME.
If any of those files are open by running services, OPatch locks out to prevent overwriting in-use binaries.
Common culprits:
- Database instances still running (
ora_pmon,ora_lgwr, etc.) - Listeners (
tnslsnr) - SQL*Plus sessions
- Monitoring agents connected via Oracle Client
Best Practices to Prevent “CheckActiveFilesAndExecutables” Errors
Shut down all databases using the same Oracle Home
sqlplus / as sysdba
SQL> shutdown immediate;
Stop all listeners
lsnrctl stop
Check for remaining Oracle processes
ps -ef | grep $ORACLE_HOME
Use fuser before patching
fuser -cu $ORACLE_HOME
Perform a dry run
opatch apply -report
Run patching during a controlled downtime
Especially for critical environments like Data Guard or RAC setups.
Internal Reference
If you are performing a full patch update, refer to this step-by-step guide:
👉 Oracle 19c Release Update 19.28 RHEL Guide
Conclusion
The “CheckActiveFilesAndExecutables failed” error is one of the most common OPatch issues DBAs encounter. It simply means that one or more Oracle executables or libraries are still in use.
By running fuser and ps -ef to identify process IDs and then safely killing those processes, you can quickly resolve the issue and reapply your patch.
Always double-check with fuser before patching and ensure that no Oracle binaries are locked. This ensures a smooth and error-free patching experience every time
