sc_serv init script for Centos

[dgcurtis]

I got tired of running sc_serv in screen and since build 123 supports a pidfile option, I wrote an init script for centos.

It uses the daemon feature of sc_serv and works very well for me. I've also attached the file so the indentations are kept.

Copy the file to /etc/init.d and then run chkconfig --add sc_serv

You'll want to change the "$daemonuser" variable to whatever user you want to run the sc_serv daemon and you should modify the "$progdir" to where your sc_serv binary is kept. If you keep your config someplace other than the same directory the sc_serv binary is located, you can change "$conffile" also.

Useful comments are welcome.

#!/bin/bash
#
# sc_serv SHOUTcast DNAS server
#
# Author: Doug Curtis <doug.curtis@world-mail.org>
#
# chkconfig: 2345 85 30
# description: The aim of the DNAS server is to provide enhanced serving features
# and also access to the new YP2 infrastructure whilst maintaining
# as much backward compatibility with previous versions of DNAS server as possible.
# processname: sc_serv
#

### BEGIN INIT INFO
# Provides: sc_serv DNAS
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop sc_serv
# Description: SHOUTcast DNAS server
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

RETVAL=0
prog="sc_serv"
progdir=/usr/local/sc_serv
daemonuser="doug"
conffile=$progdir/sc_serv.conf
lockfile=/var/lock/subsys/$prog
port=`grep portbase $conffile|cut -d= -f2`
pidfile=$progdir/$prog"_"$port.pid

status -p $pidfile -l $(basename $lockfile) >/dev/null 2>&1
running=$?

conf_check() {
[ -f $conffile ] || exit 5
}

start() {
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 1
conf_check
# Start daemons.
echo -n $"Starting $prog: "
su - $daemonuser -c "$progdir/$prog daemon $conffile" 2>/dev/null 1>&2 && success || failure $"$prog start"
RETVAL=$?
[ $RETVAL -eq 0 ] && touch $lockfile
echo
return $RETVAL
}

stop() {
# Stop daemons.
echo -n $"Shutting down $prog: "
kill -SIGTERM `cat $pidfile` 2>/dev/null 1>&2 && success || failure $"$prog stop"
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f $lockfile
echo
return $RETVAL
}

reload() {
# Reload config file.
conf_check
echo -n $"Reloading $prog: "
kill -SIGUSR1 `cat $pidfile` 2>/dev/null 1>&2 && success || failure $"$prog reload"
RETVAL=$?
echo
return $RETVAL
}

restart() {
# Stop and then start daemon.
stop
start
}

case "$1" in
start)
[ $running -eq 0 ] && exit 0
start
;;
stop)
[ $running -eq 0 ] || exit 0
stop
;;
reload)
[ $running -eq 0 ] || exit 7
reload
;;
restart)
restart
;;
status)
status -p $pidfile -l $(basename $lockfile) $prog
;;
*)
echo $"Usage: $0 {start|stop|reload|restart|status}"
exit 2
esac

exit $?

[DrO]

is good to see some use of that feature

[dgcurtis]

It looks like the newer version of sc_serv is creating the pid file in the daemon user's homedir rather than the $progdir location. The docs say "The default is to create the sc_serv_<portbase>.pid file in the same folder as the DNAS is being run from." I guess I'll have to explicitly specify the pidfile in the conf file.

[neralex]

Originally Posted by DrO

is good to see some use of that feature

OT: i'm using it also as deamon on debian and it works pretty well. For me much easier to handle than with the screen-method.

[DrO]

dgcurtis: is it definitely with build 167 that you're seeing the change ?

[dgcurtis]

I didn't see that you had replied to this thread and I just logged in to see this.

Yeah, I definitely noticed this directly after upgrading to 167. I run my shoutcast server in a VM by itself so I don't think anything else would have affected it unless they possibly changed something in a CentOS 6 upgrade.

Also, just to be sure, I went back and downgraded to 123 and it the pid is in the correct directory with specifying it in the conf.

Thanks

[DrO]

that bug was fixed in the internal builds after you'd reported it and is an issue just with that build.

[dgcurtis]

Ah, cool. It wasn't a big deal but nice to know it's fixed for future releases.

Thanks