Uno de nuestros desarrolladores tiene un servicio que debe iniciarse en el arranque. Este script debe ejecutarse:
/app/bt/preview/apache-tomcat-5.5.27/bin/startup.sh
Aquí está el script de inicio con el que estoy trabajando, llamado /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
Cuando ejecuto /etc/init.d/bt start desde la línea de comando, rc_status falla cada vez, aunque el script se inicia correctamente. No entiendo muy bien cómo se determina rc_status; ¿Es mi responsabilidad establecer el valor rc_status?
Sé que necesitaré agregar un enlace simbólico a /etc/rc.d/rc3.d, pero por ahora estoy tratando de hacerlo funcionar desde la línea de comando como root.
Respuesta aceptada:
No debe usar startproc para iniciar un shell-wrapper-script:startproc está destinado a iniciar un proceso de daemon directamente. Comprueba si el proceso está funcionando y establece su código de retorno en consecuencia.
En tu caso startup.sh no se ejecutará después del inicio de Tomcat; en su lugar, habrá un proceso Java con una bolsa de parámetros. Entonces, dado que "startup.sh" ya no se está ejecutando, startproc devolverá "fallo".