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:

# chkconfig: 2345 80 05

# Source fuction library
if [ -f /lib/lsb/init-functions ]
    . /lib/lsb/init-functions
elif [ -f /etc/init.d/functions ]
    . /etc/init.d/functions


echo $(date) >> $STARTUP_LOG    
$SU -s /bin/bash $ORACLE_OWNER -c "$LSNR start" >> $STARTUP_LOG 2>&1
$SU -s /bin/bash $ORACLE_OWNER -c "$SQLPLUS -s /nolog @$ORACLE_HOME/config/scripts/startdb.sql" >> $STARTUP_LOG 2>&1

I added the $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?

  • Do you get the same error just by trying su -s /bin/bash oracle? Jan 13, 2017 at 22:07
  • If that runs the shell properly, then you should try running (from oracle's shell) the failing commands /u01/app/oracle/product/11.2.0/xe/bin/lsnrctl and it will probably indicate a permission error. Jan 13, 2017 at 22:31
  • why did you do 'dzdo chmod 750 oracle-xe'? What permissions had the file before you changedit?
    – miracle173
    Jan 14, 2017 at 0:48
  • @JuliePelletier, the su -s /bin/bash oracle code works if I run that from the command line; I get a bash prompt with no problems. The corresponding command to lsnrctl started the listener without issue.
    – tsm
    Jan 16, 2017 at 2:55
  • @miracle173 I executed the chmod 750 following some online instructions I found. I do not know what the permissions were before I ran that command. I know the oracle-xe script is running, as I get output in the logfile. It's the su -s /bin/bash part that is failing.
    – tsm
    Jan 16, 2017 at 2:58

1 Answer 1


So I figured out what was happening. When a system is using DirectAuthorize, any account that wants to su as another user must use dzdo instead. This includes even the root account which is used to start any service via chkconfig during system boot. So I changed the following lines in my oracle-xe script file:

$SU -s /bin/bash $ORACLE_OWNER -c "$LSNR start" >> $STARTUP_LOG 2>&1
$SU -s /bin/bash $ORACLE_OWNER -c "$SQLPLUS -s /nolog @$ORACLE_HOME/config/scripts/startdb.sql" >> $STARTUP_LOG 2>&1

to this instead:

dzdo -s -u $ORACLE_OWNER $LSNR start >> $STARTUP_LOG 2>&1
dzdo -s -u $ORACLE_OWNER $SQLPLUS -s /nolog @ORACLE_HOME/config/scripts/startdb.sql >> @STARTUP_LOG 2>&1

dzdo isn't a direct replacement for su, as the options are different and you can't just simply drop it in place. In particular, there is no -c option for running a specific command with dzdo. Instead, the command to be executed is everything that appears at the end of the statement. The -s switch indicates to run a shell as the target user. After making these changes and rebooting, the listener and database instance started as user "oracle" without any hitches.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .