You may need to run root.sh again after RU patching

With the Oracle Critical Patch Update Advisory – July 2023 – you may have spotted a change in the Database Release Update READMEs: You may need to run root.sh again after RU patching. Why is that?

Let us have a quick look

I verified this with the 19.20.0 README on Linux. But I guess this applies to the other READMEs as well. Please bare in mind that this applies to the Database RUs only, not to Grid Infrastructure. You can find this new paragraph in it:

3.3.5 Update Permissions for extjob

Database release update patch installation involves relinking of libraries and executables to be updated. This can sometimes result in permissions changing and needing to be updated. Execute the following as root user:

# chown root $ORACLE_HOME/bin/extjob
# chmod 4750 $ORACLE_HOME/bin/extjob

Now I think to remember that Oracle Support has given this recommendation in the past as well. And if my memory doesn’t fool me, customers commented on the blog as well that there may be occasional issues with the permissions and the execution of external jobs.

So adjusting permissions may be a good advice, especially when you rely on the external job interface.

Of course, you’ll achieve the same result when you invoke root.sh after patching. So either solution is fine, changing permission as show above or running root.sh after patching.

 

How does it look like after patching?

At the moment, I have not had time to apply 19.20.0 – it is on my to-do list. But I read several other blog posts where people demonstrated that the extjob interface is owned by oracle:oinstall after patching – so this needs to be changed back to root‘s ownership with the correct permissions.

Especially in cases where you patch with Ansible playbooks or other tools of automation, make sure to add the call as root or sudo. Just to avoid issues.

 

And that’s not the entire story

Thanks to you, the readers, and in particular to Christian Pfundtner from Austria who pointed me to MOS Note: 1555453.1 – Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora:

Now see that the note recommends to run:

# chown root $ORACLE_HOME/bin/oradism
# chmod 4750 $ORACLE_HOME/bin/oradism

# chown root $ORACLE_HOME/bin/extjob
# chmod 4750 $ORACLE_HOME/bin/extjob

# chown root $ORACLE_HOME/rdbms/admin/externaljob.ora
# chmod 640 $ORACLE_HOME/rdbms/admin/externaljob.ora

# chown root $ORACLE_HOME/bin/jssu
# chmod 4750 $ORACLE_HOME/bin/jssu

# chown root $ORACLE_HOME/bin/nmb
# chmod 4710 $ORACLE_HOME/bin/nmb

# chown root $ORACLE_HOME/bin/nmhs
# chmod 4710 $ORACLE_HOME/bin/nmhs

# chown root $ORACLE_HOME/bin/nmo
# chmod 4710 $ORACLE_HOME/bin/nmo

when you do a relink_all which shouldn’t be the norm. So generally, there should be no need for additional relinks. But it could be the case. In such cases, it seems to be more wise to me to run root.sh instead of correcting permissions manually. I see the risk of missing something.

 

Update Oct 19, 2023

Opatch 12.2.0.1.40 includes the fix for Enh 35153024 – ER – OPATCHAUTO TO INCLUDE STEPS TO SET CORRECT OWNERSHIP AND PERMISSIONS ON EXTJOB BINARY UNDER GI HOME 

So, please use at least this (or any newer) opatch version.

 

Further Link and Information

 

–Mike

Share this: