I have a RHEL 7.2 server with Oracle 11g Express Edition (11.2.0) installed. The installation of Oracle created a file named “oracle-xe” in /etc/init.d This is a bash script that can be used to start and stop the listener and database manually. When I’m logged on to the server, I can run the following:
dzdo /etc/init.d/oracle-xe start
and the Oracle listener + database are started without issue. I can log on using sqlplus and execute commands. I’m trying to use chkconfig to make it so that oracle-xe is executed automatically on system start, so that I do not have to manually start the listener and database every time the server is rebooted. The oracle-xe script itself is lengthy, but the meat of it contains the following:
#!/bin/bash # chkconfig: 2345 80 05 # Source fuction library if [ -f /lib/lsb/init-functions ] then . /lib/lsb/init-functions elif [ -f /etc/init.d/functions ] then . /etc/init.d/functions fi SU=/bin/su ORACLE_OWNER=oracle ORACLE_HOME/bin/lsnrctl SQLPLUS=STARTUP_LOG=/home/tsm/log/oracle-xe.log echo STARTUP_LOG ORACLE_OWNER -c "STARTUP_LOG 2>&1 ORACLE_OWNER -c "ORACLE_HOME/config/scripts/startdb.sql" >> STARTUP_LOG code and the >> redirect of output so that I could sort out what was happening. I added the script to chckconfig with the following:cd /etc/init.d dzdo chmod 750 oracle-xe dzdo chkconfig --add oracle-xe dzdo chkconfig oracle-xe on
The following command yields the given (shortened) output:dzdo chkconfig --list oracle-xe 0:off 1:off 2:on 3:on 4:on 5:on 6:off
I reboot the server, and it generates a log file at /home/tsm/log/oracle-xe.log with the following output:Fri Jan 13 15:03:58 CST 2017 su: cannot open session: Permission denied su: cannot open session: Permission denied
and as you might guess, as a result of this su failure, neither the listener nor the database engine have started. Since I see the reboot date/time in the log file, I know for sure that the script is being executed upon boot. It seems to me to be a permissions issue, that whatever account is being used to execute init scripts at startup for some reason cannot su as $ORACLE_OWNER, yet me as a lowly admin can do this just fine from the command prompt. It was my understanding that the init code is executed as root, and therefore this su command should run without a problem. I've been searching and trying various things for the better part of a day trying to sort this out, and have pulled out what little remains of my hair.
The server itself is using DirectAuthorize to grant access permissions, which is why I end up using dzdo instead of sudo. Could this have something to do with it?