Olá DBAs, a vida tá boa? E vamos de patch mais uma vez. Desta vez um errinho de certa forma engraçado devido a como ele se apresenta, pois ele não é alarmado durante a checagem dos pré-requisitos, e voce só o encontra no momento da aplicação do patch.

Veja o exemplo abaixo:
[oracle@lnx 34057742]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.2.0.1.43
Copyright (c) 2025, Oracle Corporation. All rights reserved.
PREREQ session
Oracle Home : /u00/oracle/product/12.1.0.2
Central Inventory : /u00/oracle/oraInventory
from : /u00/oracle/product/12.1.0.2/oraInst.loc
OPatch version : 12.2.0.1.43
OUI version : 12.1.0.2.0
Log file location : /u00/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2025-02-06_10-29-17AM_1.log
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
Verificação básica de pré-requisitos para aplicação do patch feita com sucesso, sem erros, status PASSED.
Então já que está tudo lindo, maravilhoso e fofo, vamos executar o patch:
[oracle@lnx 34057742]$ $ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.43
Copyright (c) 2025, Oracle Corporation. All rights reserved.
Oracle Home : /u00/oracle/product/12.1.0.2
Central Inventory : /u00/oracle/oraInventory
from : /u00/oracle/product/12.1.0.2/oraInst.loc
OPatch version : 12.2.0.1.43
OUI version : 12.1.0.2.0
Log file location : /u00/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2025-02-10_07-46-47AM_1.log
Verifying environment and performing prerequisite checks...
Prerequisite check "CheckApplicable" failed.
The details are:
Patch 31113348:
DeleteAction : Destination File "/u00/oracle/product/12.1.0.2/oc4j/ant/lib/ant-apache-log4j.jar.previous" is not writeable.
'oracle.javavm.containers, 12.1.0.2.0': Cannot delete file '/u00/oracle/product/12.1.0.2/oc4j/ant/lib/ant-apache-log4j.jar.previous'
UtilSession failed:
Prerequisite check "CheckApplicable" failed.
Log file location: /u00/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2025-02-10_07-46-47AM_1.log
OPatch failed with error code 73
Droga!!! Porque deu um erro que não apareceu nos pré-reqs? Bom, o problema está bem claro e descrito, mas, vamos verificar o log em questão:
[oracle@lnx 34057742]$ more /u00/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2025-02-10_07-46-47AM_1.log
[Feb 10, 2025 7:46:47 AM] [INFO] CAS Dynamic Loading :
........
[Feb 10, 2025 7:46:58 AM] [INFO] Patch 31113348:
DeleteAction : Destination File "/u00/oracle/product/12.1.0.2/oc4j/ant/lib/ant-apache-log4j.jar.previous" is not writeable.
'oracle.javavm.containers, 12.1.0.2.0': Cannot delete file '/u00/oracle/product/12.1.0.2/oc4j/ant/lib/ant-apache-log4j.jar.previous'
[Feb 10, 2025 7:47:00 AM] [INFO] Prerequisite check "CheckApplicable" failed.
The details are:
Patch 31113348:
DeleteAction : Destination File "/u00/oracle/product/12.1.0.2/oc4j/ant/lib/ant-apache-log4j.jar.previous" is not writeable.
'oracle.javavm.containers, 12.1.0.2.0': Cannot delete file '/u00/oracle/product/12.1.0.2/oc4j/ant/lib/ant-apache-log4j.jar.previous'
[Feb 10, 2025 7:47:00 AM] [SEVERE] OUI-67073:UtilSession failed:
Prerequisite check "CheckApplicable" failed.
[Feb 10, 2025 7:47:00 AM] [INFO] Finishing UtilSession at Mon Feb 10 07:47:00 EST 2025
[Feb 10, 2025 7:47:00 AM] [INFO] Log file location: /u00/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2025-02-10_07-46-47AM_1.log
[Feb 10, 2025 7:47:00 AM] [INFO] Stack Description: java.lang.RuntimeException:
Prerequisite check "CheckApplicable" failed.
at oracle.opatch.OPatchSessionHelper.runApplyPrereqs(OPatchSessionHelper.java:6612)
at oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:1106)
at oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:373)
at oracle.opatch.opatchutil.NApply.process(NApply.java:353)
at oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1139)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at oracle.opatch.UtilSession.process(UtilSession.java:355)
at oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
at oracle.opatch.OPatch.process(OPatch.java:885)
at oracle.opatch.OPatch.main(OPatch.java:942)
Caused by: java.lang.RuntimeException:
Prerequisite check "CheckApplicable" failed.
... 13 more
Caused by: oracle.opatch.PrereqFailedException:
Prerequisite check "CheckApplicable" failed.
... 13 more
Hmmmmm… Só confirmando que o arquivo problemático descrito no log nãopode ser manipulado pelo meu patch corrente, porque será? Vamos checar o arquivo:
[oracle@lnx 34057742]$ cd /oracle/product/12.1.0.2/oc4j/ant/lib/
[oracle@lnx lib]$ ls -ltrh | grep .previous
-rw-r--r--. 1 root root 3.0K Mar 11 2022 ant-apache-log4j.jar.previous
Olha só! O arquivo pertence ao root. Eu estou executando o patch como usuário “oracle”, faz todo sentido caso esse arquivo possa ser manipulado pelo usuário atual. Mas porque este arquivo está com o root como owner?
Bom, é um arquivo log4j, me lembro destes arquivos estarem citados num CVE como vulneráveis e de haverem patches de correção, então pesquisando um pouco encontrei as informações. Durante os patches contra vulnerabilidades do CVE-2021-44228, arquivos antigos de Log4j foram substituídos e mantidos com .previous para garantir rastreamento e para que assim, com essa extensão eles não sejam carregados no classpath apesar de existirem no diretório. O processo de opatch muda o owner dos arquivos, para evitar mudanças acidentais e uso indevido. Em resumo estes arquivos existem somente como backup/histórico e, nestes casos é comum que o arquivo de backup seja alterado para o root (provavelmente este patch de segurança do CVE também foi aplicado como root, e isso é mais comum ainda em ambiente GI onde voce executa os patches como root).
Sendo assim, o que posso fazer para resolver essa pendenga? Bom meus queridos, existem diversas maneiras de preparar Neston (somente quem é das antigas vai entender essa). Vamos lá:
- Apagar o arquivo
- Se o patch de segurança foi aplicado com sucesso estes arquivos são somente backup, então voce pode apagá-lo.
- O ambiente está estável desde a aplicação do patch de segurança, então voce pode apagá-lo.
- Voce está ciente que não pode reverter esse patch de segurança se apagar o arquivo, então voce pode apagá-lo.
- Para ambientes críticos, recomendo fazer um backup em outra pasta fora do OH e , então voce pode apagá-lo.
- Alterar o dono do arquivo
- Voce pode alterar o dono do arquivo para o usuário oracle novamente sem maiores problemas.
- Recomendo voltar o dono do arquivo ao root após a aplicação do patch corrente, para evitar riscos do arquivo ser usado indevidamente.
- Usar a opção -force ao aplicar o patch corrente
- Ele irá ignorar os arquivos e aplicar o patch devidamente.
- Não recomendado quando não se tem certeza da relevancia destes arquivos para o OH.
Bom, sendo assim, no meu caso específico eu preferi a segunda opção, onde alterei o dono dos arquivos no SO e depois iria voltá-lo ao root como anteriormente. Num futuro patch, com certeza total da irrelevancia destes arquivos, farei um backup e os apagarei, mas por enquanto:
[oracle@lnx lib]$ sudo chown oracle:dba ant-apache-log4j.jar.previous
[oracle@lnx lib]$ ls -ltrh
-rw-r--r--. 1 oracle dba 3.0K Mar 11 2022 ant-apache-log4j.jar.previous
Pronto! Após essa pequena alteração no owner do arquivo (pode ser que voce tenha mais arquivos que precisem ser alterados) o patch rodou liso e sem maiores intercorrencias.
Após o patch eu alterei de volta para o root, e em uma próxima oportunidade eu removerei estes arquivos (obviamente com backup pois eu posso até ter nascido ontem, mas foi de manhã).
Como sempre, Fiquem a vontade para fazer quaisquer pontuações caso já tenham vivenciado algo do tipo.
Essa é a dica 0800 pra vocês desta vez.
“Saber das coisas vale ouro. Compartilhar esse conhecimento não tem preço.”
