I am sharing a situation that happened after an Oracle upgrade from 220.127.116.11 to 18.104.22.168, although I can imagine this can happen at any time.
This is on AIX.
After the upgrade, the oracle processes were running as sidadm, which could be a problem:
the permissions of the oracle executable at $ORACLE_HOME/bin were set correctly with the correct s-bits set:
As we read in SAP note 206916 , ps -ef does not show the effective user which is the user actually running the process, but only the real user who ran the process.
This can be checked by running the command “ps -ef -o comm=command,args=argument,ruser,user”:
On the right you can see 2 users. The first one is RUSER column which is the real user, this is what normal ps -ef shows us.
The user next to that more to the right is the USERS column which is the effective user. This must always be orasid.
So this database should in theory run fine, but still something has happened to cause this. We assumed the problem was some permission setting somewhere was set to sidadm and not orasid, but we could find that anywhere.
A few test revealed that if we start the listener with sidadm, the above happens. So stopping the listener and starting again with orasid solved it. A restart will be required as the current open processes will have an established connections.