Rc_status renvoie toujours "échec" ?

L'un de nos développeurs a un service qui doit être démarré au démarrage. Ce script doit être exécuté :

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

Voici le script de démarrage avec lequel je travaille, appelé /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

Lorsque je lance /etc/init.d/bt start à partir de la ligne de commande, le rc_status échoue à chaque fois, même si le script démarre correctement. Je ne comprends pas très bien comment rc_status est déterminé ; est-ce ma responsabilité de définir la valeur rc_status ?

Je sais que je devrai ajouter un lien symbolique à /etc/rc.d/rc3.d, mais pour l'instant j'essaie de le faire fonctionner à partir de la ligne de commande en tant que root.

Réponse acceptée :

Vous ne devez pas utiliser startproc pour démarrer un shell-wrapper-script :startproc est destiné à démarrer directement un processus démon. Il vérifie si le processus est opérationnel et définit son code de retour en conséquence.

Dans votre cas startup.sh ne fonctionnera pas après le démarrage de Tomcat - il y aura un processus Java avec un sac de paramètres à la place. Donc, puisque "startup.sh" ne s'exécute plus, startproc renverra "échec".