标题: Opatchauto Does Not Stop CRS as Prepatch Is Not Getting Executed [打印本页] 作者: 刘泽宇 时间: 2025-8-10 18:28 标题: Opatchauto Does Not Stop CRS as Prepatch Is Not Getting Executed 现象：
opatchauto command getting failed with below errors
Oct 20, 2024 10:07:17 PM] [INFO] Following active files/executables/libs are used by ORACLE_HOME :/u01/app/19c/grid
/u01/app/19c/grid/bin/oracle
[Oct 20, 2024 10:07:17 PM] [INFO] Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:
Following active files/executables/libs are used by ORACLE_HOME :/u01/app/19c/grid
/u01/app/19c/grid/bin/oracle
[Oct 20, 2024 10:07:21 PM] [SEVERE] OUI-67073:UtilSession failed: Prerequisite check "CheckActiveFilesAndExecutables" failed.
[Oct 20, 2024 10:07:21 PM] [INFO] Finishing UtilSession at Sun Oct 20 22:07:21 EDT 2024
While checking further we can see CRS is running fine and prepatch operation was not executed which will stop CRS followed by patching.
改动：
System admin team introduced auto scripting on user logins to audit the system few months before.
原因：
Customers has a custom script to audit the sessions and that script is preventing the opatchauto to execte the commands properly resulting in time out.
From patching logs.
2024-10-20 21:54:14,724 INFO [264] com.oracle.glcm.patch.auto.db.product.executor.GISystemCall - System Call command is: [/bin/su, -, root, -m, -c, bash -c "LD_LIBRARY_PATH=/u01/app/19c/grid/lib:/u01/app/19c/grid/srvm/lib:/u01/app/patches/36916690/36917416/files/lib:/u01/app/19c/grid/lib:/u01/app/19c/grid/lib:/u01/app/19c/grid/srvm/lib:/u01/app/19c/grid/lib:/u01/app/19c/grid/srvm/lib /u01/app/19c/grid/perl/bin/perl -I/u01/app/19c/grid/perl/lib -I/u01/app/19c/grid/opatchautocfg/db/dbtmp/bootstrap_node1/patchwork/crs/install -I/u01/app/19c/grid/opatchautocfg/db/dbtmp/bootstrap_node1/patchwork/xag /u01/app/19c/grid/opatchautocfg/db/dbtmp/bootstrap_node1/patchwork/crs/install/rootcrs.pl -prepatch"]
2024-10-20 22:04:14,988 INFO [264] com.oracle.glcm.patch.auto.db.product.executor.GISystemCall - Error message:su: ignoring --preserve-environment, it's mutually exclusive with --login
2024-10-20 22:04:14,988 INFO [264] com.oracle.glcm.patch.auto.db.product.executor.GISystemCall - Output message:Script started, file is /var/log/rootlogs/root.102024.21:54:14.2854110.out
]0;root@node1:~[root@VM:node1 ~]# timed out waiting for input: auto-logout
Script done, file is /var/log/rootlogs/root.102024.21:54:14.2854110.out
2024-10-20 22:04:14,988 INFO [264] com.oracle.glcm.patch.auto.db.product.executor.GISystemCall - Return code: 0
2024-10-20 22:04:14,988 INFO [264] com.oracle.glcm.patch.auto.db.product.executor.PatchingStepExecutor - status: 0
2024-10-20 22:04:14,988 INFO [264] com.oracle.glcm.patch.auto.db.product.executor.PatchingStepExecutor - Successfully executed the above command.
处理方法：
After removing customer's custom script from the system, opacthauto execution was successful and patches applied without any issues.
"opatchauto" in turn executes multiple commands. Custom commands/scripts should not interrupt these executions.
In this case while opatchauto execute "prepatch" operations its getting timed out due to the custom script.
If this script is required, DBA needs to work further with their system admin team to make sure it wont interrupt with the oracle patching.
If still need to have the script in place, then as a workaround customer may use manual patching to apply the patches.
Refer 2246888.1 for more details on steps to apply patches manually