rc_status always returns "failed"

Question

One of our developers has a service that needs to be started on boot. This script needs to be fired:

/app/bt/preview/apache-tomcat-5.5.27/bin/startup.sh

Here is the startup script I'm working with, called /etc/init.d/bt:

#!/bin/sh
#
### BEGIN INIT INFO
# Provides:          BTServer
# Required-Start:    $local_fs $network $remote_fs
# Required-Stop:     $local_fs $network $remote_fs
# Should-Start:
# Should-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: BT Server
# Description:       BT Server
### END INIT INFO
#
#
# Run BT startup scripts as btu user
#
# Location of startup script
BT_SCR='/app/bt/preview/apache-tomcat-5.5.27/bin/startup.sh'

test -x $BT_SCR || exit 5

# Set up rc_status command
. /etc/rc.status
rc_reset

case "$1" in
start)
        echo -n "Starting BT Server"
        startproc -u btu $BT_SCR
        rc_status -v
        ;;
        *)
        echo "Usage: $0 { start }"
        exit 1

        ;;
esac
exit 0

When I run /etc/init.d/bt start from the command line, the rc_status is failed every time, even though the script starts up fine. I don't quite understand how rc_status is determined; is it my responsibility to set the rc_status value?

I know I'll need to add a symlink to /etc/rc.d/rc3.d, but for now I'm trying to get it working from the command line as root.

Answer 1

You should not use startproc for starting a shell-wrapper-script: startproc is meant to start a daemon-process directly. It checks if the process is up and running and sets its return-code accordingly.

In your case startup.sh won`t be running after Tomcat startup - there will be a java-process with a bag of parameters instead. So since "startup.sh" is not running any more, startproc will return "failure".

Answer 2

I found this here on StackOverflow. They say there that

rc_status ... sets the "status value", which is the return value returned by rc_exit (which you place at the end of your init.d script)

Answer 3

You could take a look how I handled it in my RPM packages in devops-incubator :

https://github.com/hgomez/devops-incubator/blob/master/rpm-packaging/myjenkins/SOURCES/initd.skel