Fixing OPatch Error: “Prerequisite check ‘CheckActiveFilesAndExecutables’ failed” — Real Production Experience

By Chakravarthy
July 30, 2026 6 Min Read

Patching Oracle environments is usually straightforward — until it isn’t.

Nothing kills a maintenance window faster than OPatch stopping with:

Prerequisite check “CheckActiveFilesAndExecutables” failed

I recently hit this repeatedly while applying quarterly patches across multiple 19c environments (both Grid Infrastructure and Database homes). In this article I’ll walk through what caused the issue, how I diagnosed it, and the exact steps I used to fix it — all from real production systems.

Understanding the Error

OPatch performs several prerequisite checks before applying a patch. One of them ensures that no active processes are holding Oracle binaries or shared libraries.

If any executable or shared object (like libclntsh.so, libsqlplus.so, or tnslsnr) is in use, OPatch fails with:

Prerequisite check “CheckActiveFilesAndExecutables” failed.

This typically happens when:

  • A user is still running sqlplus
  • A listener is still running
  • A Java installer process is active
  • OEM/OMS components are still up
  • Background processes are holding shared libraries

Scenario 1: OPatchAuto Failure in Grid Infrastructure Home

During an OPatchAuto session, the database home patched successfully, but the Grid home failed:

Failed during Patching: OPatchException: Prerequisite check "CheckActiveFilesAndExecutables" failed.
/u01/app/19.3.0/grid/OPatch/opatchauto apply /u01/app/oracle/software/patches/19.15.0/33859214/33803476

OPatchauto session is initiated at Tue Apr  2 18:48:33 2025

System initialization log file is /u01/app/19.3.0/grid/cfgtoollogs/opatchautodb/systemconfig2025-04-02_06-48-38PM.log.

Session log file is /u01/app/19.3.0/grid/cfgtoollogs/opatchauto/opatchauto2025-04-02_06-48-43PM.log
The id for this session is CPMB

Executing OPatch prereq operations to verify patch applicability on home /u01/app/19.3.0/db
Patch applicability verified successfully on home /u01/app/19.3.0/db

Executing patch validation checks on home /u01/app/19.3.0/db
Patch validation checks successfully completed on home /u01/app/19.3.0/db

Verifying SQL patch applicability on home /u01/app/19.3.0/db
SQL patch applicability verified successfully on home /u01/app/19.3.0/db

Start applying binary patch on home /u01/app/19.3.0/db
Binary patch applied successfully on home /u01/app/19.3.0/db

Start applying binary patch on home /u01/app/19.3.0/grid
Failed while applying binary patches on home /u01/app/19.3.0/grid

Execution of [OPatchAutoBinaryAction] patch action failed, check log for more details. Failures:
Patch Target : oraclestdby->/u01/app/19.3.0/grid Type[siha]
Details: [
---------------------------Patching Failed---------------------------------
Command execution failed during patching in home: /u01/app/19.3.0/grid, host: orclprd.
==Following patches FAILED in apply:

Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33806152
Log: /u01/app/19.3.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2025-04-02_19-08-52PM_1.log
Reason: Failed during Patching: oracle.opatch.opatchsdk.OPatchException: Prerequisite check "CheckActiveFilesAndExecutables" failed.

OPatchauto session completed at Tue Apr  2 19:10:03 2025
Time taken to complete the session 21 minutes, 30 seconds

 opatchauto failed with error code 42

To identify the culprit, I checked which process was locking the shared library:

/sbin/fuser /u01/app/19.3.0/grid/lib/libclntsh.so.19.1
/u01/app/19.3.0/grid/lib/libclntsh.so.19.1: 76792m

Output showed a Java process holding the file. After confirming with ps -ef, I terminated it:

ps -ef | grep 76792
oracle     76792    6786  0 17:54 pts/1    00:00:03 /u01/app/19.3.0/grid/jdk/jre/bin/java -Doracle.installer.not_bootstrap=true -DCV_HOME=/u01/app/19.3.0/grid

Terminated the leftover Java process:

kill -9 76792
Note: Prefer a graceful stop whenever possible. Use kill -9 only as a last resort.

Re-running fuser confirmed the file was no longer in use.

/sbin/fuser /u01/app/19.3.0/grid/lib/libclntsh.so.19.1

Then I resumed the patch:

/u01/app/19.3.0/grid/OPatch/opatchauto resume

OPatchauto session is initiated at Tue Apr  2 19:18:18 2025
Session log file is /u01/app/19.3.0/grid/cfgtoollogs/opatchauto/opatchauto2025-04-02_07-18-18PM.log
Resuming existing session with id CPMB

Start applying binary patch on home /u01/app/19.3.0/grid
Binary patch applied successfully on home /u01/app/19.3.0/grid


Preparing home /u01/app/19.3.0/db after database service restarted

Trying to apply SQL patch on home /u01/app/19.3.0/db
SQL patch applied successfully on home /u01/app/19.3.0/db

OPatchAuto successful.

--------------------------------Summary--------------------------------

Patching is completed successfully. Please find the summary as follows:

==Following patches were SUCCESSFULLY applied:
Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33806152
Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33815596
==Following patches were SUCCESSFULLY applied:
Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33806152
Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33815596
Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33815607
Patch: /u01/app/oracle/software/patches/19.15.0/33859214/33803476/33911149

OPatchauto session completed at Tue Apr  2 19:31:35 2025
Time taken to complete the session 13 minutes, 17 seconds

Scenario 2: OPatch Failure in OEM / DB Home

While applying a patch manually:

$ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.29

Oracle Home       : /u01/app/19.3.0/db
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/19.3.0/db/oraInst.loc
OPatch version    : 12.2.0.1.29
OUI version       : 12.2.0.7.0
Log file location : /u01/app/19.3.0/db/cfgtoollogs/opatch/opatch2022-10-21_06-02-03AM_1.log

Verifying environment and performing prerequisite checks...
Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:


Following active executables are not used by opatch process :
/u01/app/19.3.0/db/lib/libclntsh.so.19.1
/u01/app/19.3.0/db/bin/oracle

Following active executables are used by opatch process :
/u01/app/19.3.0/db/lib/libsqlplus.so
/u01/app/19.3.0/db/lib/libasmclntsh19.so
/u01/app/19.3.0/db/bin/tnslsnr

UtilSession failed: Prerequisite check "CheckActiveFilesAndExecutables" failed.
Log file location: /u01/app/19.3.0/db/cfgtoollogs/opatch/opatch2022-10-21_06-02-03AM_1.log

OPatch failed with error code 73

Identifying the processes:

/sbin/fuser /u01/app/19.3.0/db/lib/libclntsh.so.19.1
/u01/app/19.3.0/db/lib/libclntsh.so.19.1: 16362m 27274m

This time, the listener and a sqlplus session were active.

ps -ef | grep -v grep | grep  16362
oracle   16362     1  0 Oct17 ?        00:00:23 /u01/app/19.3.0/db/bin/tnslsnr LISTENER -inherit

ps -ef | grep -v grep | grep  27274
oracle   27274 22796  0 Oct18 pts/1    00:00:03 sqlplus

I stopped the listener cleanly:

lsnrctl stop

Terminated the leftover sqlplus session:

kill -9 27274

After clearing the locks, OPatch proceeded without issues and the patch was applied successfully.

$ORACLE_HOME/OPatch/opatch apply

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   31281355

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/19.3.0/db')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '31281355' to OH '/u01/app/19.3.0/db'

Patching component oracle.rdbms, 19.0.0.0.0...

Patching component oracle.rdbms.util, 19.0.0.0.0...

Patching component oracle.rdbms.rsf, 19.0.0.0.0...

Patching component oracle.assistants.acf, 19.0.0.0.0...

Patching component oracle.assistants.deconfig, 19.0.0.0.0...

Patching component oracle.assistants.server, 19.0.0.0.0...

Patching component oracle.buildtools.rsf, 19.0.0.0.0...

Patching component oracle.ctx, 19.0.0.0.0...

Patching component oracle.dbjava.ic, 19.0.0.0.0...

Patching component oracle.ldap.rsf, 19.0.0.0.0...

Patching component oracle.network.rsf, 19.0.0.0.0...

Patching component oracle.rdbms.dbscripts, 19.0.0.0.0...

Patching component oracle.rdbms.deconfig, 19.0.0.0.0...

Patching component oracle.sdo, 19.0.0.0.0...

Patching component oracle.sdo.locator.jrf, 19.0.0.0.0...

Patching component oracle.sqlplus, 19.0.0.0.0...

Patching component oracle.xdk, 19.0.0.0.0...

Patching component oracle.rdbms.crs, 19.0.0.0.0...

Patching component oracle.install.deinstalltool, 19.0.0.0.0...

Patching component oracle.dbjava.ucp, 19.0.0.0.0...

Patching component oracle.oraolap.dbscripts, 19.0.0.0.0...

Patching component oracle.rdbms.lbac, 19.0.0.0.0...

Patching component oracle.dbdev, 19.0.0.0.0...

Patching component oracle.marvel, 19.0.0.0.0...

Patching component oracle.network.listener, 19.0.0.0.0...

Patching component oracle.precomp.rsf, 19.0.0.0.0...

Patching component oracle.javavm.client, 19.0.0.0.0...

Patching component oracle.precomp.common.core, 19.0.0.0.0...

Patching component oracle.ldap.rsf.ic, 19.0.0.0.0...

Patching component oracle.network.client, 19.0.0.0.0...

Patching component oracle.ctx.atg, 19.0.0.0.0...

Patching component oracle.ctx.rsf, 19.0.0.0.0...

Patching component oracle.rdbms.drdaas, 19.0.0.0.0...

Patching component oracle.duma, 19.0.0.0.0...

Patching component oracle.javavm.server, 19.0.0.0.0...

Patching component oracle.odbc, 19.0.0.0.0...

Patching component oracle.rdbms.oci, 19.0.0.0.0...

Patching component oracle.rdbms.rman, 19.0.0.0.0...

Patching component oracle.rdbms.dv, 19.0.0.0.0...

Patching component oracle.bali.ice, 11.1.1.7.0...

Patching component oracle.ovm, 19.0.0.0.0...

Patching component oracle.dbjava.jdbc, 19.0.0.0.0...

Patching component oracle.oracore.rsf, 19.0.0.0.0...

Patching component oracle.rdbms.scheduler, 19.0.0.0.0...

Patching component oracle.rdbms.install.common, 19.0.0.0.0...

Patching component oracle.ldap.owm, 19.0.0.0.0...

Patching component oracle.ldap.security.osdt, 19.0.0.0.0...

Patching component oracle.ons, 19.0.0.0.0...

Patching component oracle.rdbms.install.plugins, 19.0.0.0.0...

Patching component oracle.sdo.locator, 19.0.0.0.0...

Patching component oracle.nlsrtl.rsf, 19.0.0.0.0...

Patching component oracle.xdk.rsf, 19.0.0.0.0...

Patching component oracle.sqlplus.ic, 19.0.0.0.0...

Patching component oracle.oraolap, 19.0.0.0.0...

Patching component oracle.xdk.parser.java, 19.0.0.0.0...

Patching component oracle.rdbms.rsf.ic, 19.0.0.0.0...

Patching component oracle.precomp.common, 19.0.0.0.0...

Patching component oracle.precomp.lang, 19.0.0.0.0...

Patching component oracle.jdk, 1.8.0.201.0...
Patch 31281355 successfully applied.
Sub-set patch [29517242] has become inactive due to the application of a super-set patch [31281355].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /u01/app/19.3.0/db/cfgtoollogs/opatch/opatch2022-10-21_06-04-41AM_1.log

OPatch succeeded..

Scenario 3: OPatchAuto Failure in Database Home

In another environment, OPatchAuto failed during the database home patching phase. Again, libclntsh.so.19.1 was locked by a sqlplus session.

Once the process was terminated and the file was free, resuming OPatchAuto completed the patch successfully.

Root Cause Summary

Across all environments the root cause was consistent:

Active processes were holding Oracle shared libraries.

Common culprits:

  • sqlplus
  • tnslsnr
  • OEM/OMS components
  • Java installer processes
  • Background sessions left open by users

How to Fix the Error (Step-by-Step)

  1. Identify the locking process
/sbin/fuser $ORACLE_HOME/lib/libclntsh.so.19.1
  1. Find the process details
ps -ef | grep <PID>
  1. Stop the service or kill the process

Prefer graceful stop first:

lsnrctl stop

If needed:

kill -9 <PID>
  1. Verify the file is no longer in use
/sbin/fuser $ORACLE_HOME/lib/libclntsh.so.19.1
  1. Resume / re-run patching
  • For OPatchAuto: opatchauto resume
  • For manual OPatch: opatch apply

Best Practices to Avoid This Error

  • Stop listeners before patching
  • Ensure no users are logged in with sqlplus
  • Stop OEM/OMS services when patching OMS or agent homes
  • Run fuser proactively before starting the patch
  • Always review logs under $ORACLE_HOME/cfgtoollogs/opatch*

Final Thoughts

This error is common, but the fix is straightforward once you know where to look. The key is identifying which process is locking the shared library and clearing it before (or during) patching.

Real-world troubleshooting like this is what keeps Oracle environments stable and patching predictable.

Tags:

No Comment! Be the first one.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright 2026 — Forerunner DBA. All rights reserved.