Olá DBAs, a vida tá boa? Hoje vamos de um caso de erro no patch, que dá um sustinho no início, mas depois de verificado a gente fica mais sossegado. Não é nada demais, até a gente descobrir que não é nada demais. Vambora!!!
Mais uma vez por essas andanças de patch apply da vida, esses dias ao aplicar um patch me deparei com o seguinte erro ao final:
...
Patching component oracle.ldap.rsf.ic, 12.1.0.2.0...
Patching component oracle.rdbms.dbscripts, 12.1.0.2.0...
Patching component oracle.rdbms.hsodbc, 12.1.0.2.0...
OPatch found the word "error" in the stderr of the make command.
Please look at this stderr. You can re-run this make command.
Stderr output:
chmod: changing permissions of ‘/u01/oracle/product/12.1.0.2/bin/extjobO’: Operation not permitted
make: [iextjob] Error 1 (ignored)
Composite patch 34057742 successfully applied.
OPatch Session completed with warnings.
Log file location: /u01/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2025-05-15_23-14-13PM_1.log
Apesar de aparecer como um erro, no final vemos que ele é “rebaixado” a somente um “warning”. Ou seja, ele foi aplicado com sucesso, mas ficou uma coisinha sabe…
Em termos é uma boa notícia, mas a primeira coisa que nos vem a mente é: E agora, José?
Isso pode impactar o sucesso do meu patch? Pode ter consequências?
Bom, a mensagem diz que podemos executar o comando “make” manualmente, mas, mesmo que voce faça isso, receberá o mesmo erro, pois a causa continua lá. Em resumo, o arquivo extjobO está pertencendo ao root, deixando a operação terminar como deveria, mas com este arquivo sendo alarmado como um empecilho para o patch sair “liso”.
Se tratando de um patch, a primeira coisa que deveríamos olhar é a seção “Know issues” do readme. A segunda coisa é o nosso querido amigo Oracle Support (metalink pra já era grande na Copa de 2002). E por último sair caçando em blogs e outros documentos na Internet. Esse é pra ser o procedimento padrão, mas nem sempre vamos pelo mais óbvio, dependendo do nível de stress e adrenalina no momento, a gente já sai de Google na veia. Se voce tá lendo esse artigo no meu blog, já entendeu do que eu to falando 🙂
Então, vamos pelo mais óbvio e correto. No meu caso estrava aplicando o DB PSU 12.1.0.2.220719, mais especificamente o patch 34057742, então vamos ao readme do bichão, procurar se ele consta na sessão “Know Issues”.
Well, well, well. Após olhar o readme, olhem o que encontrei?
Referente ao erro, nada! Bom, mais tranquilo com a minha consciencia, já que não olhei aqui primeiro 🙂
Fato curioso e engraçado é que este erro está descrito claramente e explicitamente no readme do Patch 24968615 – Database Proactive Bundle Patch 12.1.0.2.170117 de 2017, mas não está no PSU de 2022. Fazer o que né?
Bom, voltando o MEU patch específico, já que não encontrei no readme, vamos ao MOS, e pesquisando encontrei o seguinte DOCID: Applying Proactive Bundle / PSU Patch fails with Error: “chmod: changing permissions of `$ORACLE_HOME/bin/extjobO’: Operation not permitted” (Doc ID 2265726.1)
Bom, o erro é aplicável tanto em DPBP quando em PSU. Show! Agora vamos ver o que ele diz:
"Generally the permissions of some Oracle executables have to be changed on Linux/Unix after the installation. This is done by “root.sh”
i.e, ownership of extjob, jssu and oradism was changed to “root” by root.sh
After applying patch the permissions get changed. As external jobs are rarely used."Sim, o arquivo está assim de propósito, pois a troca do owner é feita pelo instalador, e a descrição da causa no DOCID é o mais legal:
Cause: This is due to the defect for which an internal bug is raised.
Oracle Support (Doc ID 2265726.1)
Bom, bugzinho maroto, só pra dar susto na gente, mas pelo menos causa, consequencia e reação documentada. E o que fazer quando enfrentamos esse erro no patch?
Nada!
Repito: NADA!
Esse erro pode ser seguramente ignorado, segundo o fabricante, e você não precisa se preocupar com ele.
Verifiquei nos meus servidores e, em todos onde peguei esse erro, o arquivo extjobO pertence ao root. Mas, curiosamente, em vários outros, o arquivo pertence ao usuário oracle. Por se tratar de um bug, não dá pra cravar quais são as condições que levam à troca de owner ou não.
Você até pode rodar o root.sh novamente, se quiser, e tentar o make conforme descrito no DOCID, mas minha opinião é:
Se não é necessário, pra que cutucar vespeiro?
Resumindo, voce leu até aqui só pra ter certeza de que não precisa fazer absolutamente nada nesse caso, só seguir a vida, e que o susto inicial ao verificar um erro no seu patch, neste caso específico, é só pra dar emoção naquela janela apertada de produção que voce tem.
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.”
