Not easy to detect, and depending on the product (agent/database), it may have only limited side effects.
Like external jobs not running, operating systems statistics not collected.
But it is not always easy to diagnose.
For instance if you patch from OMS 12cR2 to 12cR3, and you run the root.sh only in 12cR2, they are very few statistics missing (one is the OS_STORAGE_ENTITY).
Running the root.sh doesn’t generate a log file or an entry in the inventory.
To check if it was executed, check what it is supposed to do. It is a bit different in each version. One think it always does is changing the ownership to root and set the sticky bit for a few binaries. For the database, this is done in sub-scripts called rootadd.sh (10g) or rootadd_rdbms.sh (11g/12c).
eval ls -l $(find $ORACLE_HOME -name "rootadd*sh" -exec awk '$1="$CHOWN"&&$2=="root"{print $3}' {} \;|sort -u)
-rwsr-x--- root dba .../product/11.2.0/db_4/bin/extjob
-rwsr-x--- root dba .../product/11.2.0/db_4/bin/jssu
-rws--x--- root dba .../product/11.2.0/db_4/bin/nmb
-rws--x--- root dba .../product/11.2.0/db_4/bin/nmhs
-rws--x--- root dba .../product/11.2.0/db_4/bin/nmo
-rwsr-x--- root dba .../product/11.2.0/db_4/bin/oradism
-rw-r----- root dba ...11.2.0/db_4/rdbms/admin/externaljob.ora
If the ownership is root, you definitely did run the root.sh.
On the 12c agent, there is a FULL_BINARY_LIST variable that point to list of root binaries in sbin
eval $(grep FULL_BINARY_LIST= $AGENT_HOME/root.sh)
cd $AGENT_HOME/../../sbin
ls -l $FULL_BINARY_LIST
-rws--x--- root dba nmb
-rws--x--- root dba nmhs
-rws--x--- root dba nmo
If all files exist and belong root, it looks like you did run the root.sh.
Hi Laurent – I agree it’s often difficult to check whether root.sh has been run. For the database, I think there is a log file that gets written under $ORACLE_HOME/install called root.log (or similar). But it doesn’t help very much. It’s also confusing how more recent versions of root.sh don’t set the permissions for the $ORACLE_HOME/bin/oracle binary.
Thanks for the hint. I have an empty root.log in the database install log, but it does not belongs oracle. And for the agent, I have nothing.
Just been looking at whether the root.sh has been run across our estate. Thanks for the pointer to the FULL_BINARY_LIST variable in the agent root.sh script. The list of executables in the FULL_JOB_EXECUTABLES is also useful.
It’s a shame that the agent root.sh doesn’t write a log file. I ended up writing an OEM metric extension to check the ownership and permissions of the binaries in order to see if the agent root.sh has not been run on each host following a set of agent upgrades.
Have a quick question.. I’m upgrading agents from 12.1.0.4 to 12.1.0.5. During upgrade root.sh must be run manually because we do not use preferred host credentials and we do not have oracle user password to set user credential. All files in AH/sbin already owned by root:dba from the previous agent install. Should i still need to run root.sh? Running root.sh from the new OH does not change anything , only updates files timestamp.
I believe is you run repvfy verify -level 9 -detail it will also list all the agents where you have missed running root.sh
Hi ,
What happened if i dint run the root.sh after deployed as agent?
does it has any impact ?