6.5 Starting Services

It is common for a system to host a number of services. These may be started in several different fashions, each having different advantages.

Software installed from a port or the packages collection will often place a script in /usr/local/etc/rc.d which is invoked at system startup with a start argument, and at system shutdown with a stop argument. This is the recommended way for starting system-wide services that are to be run as root, or that expect to be started as root. These scripts are registered as part of the installation of the package, and will be removed when the package is removed.

A generic startup script in /usr/local/etc/rc.d looks like:

#!/bin/sh
echo -n ' FooBar'

case "$1" in
start)
        /usr/local/bin/foobar
        ;;
stop)
        kill -9 `cat /var/run/foobar.pid`
        ;;
*)
        echo "Usage: `basename $0` {start|stop}" >&2
        exit 64
        ;;
esac

exit 0
    

The startup scripts of DragonFly will look in /usr/local/etc/rc.d for scripts that have an .sh extension and are executable by root. Those scripts that are found are called with an option start at startup, and stop at shutdown to allow them to carry out their purpose. So if you wanted the above sample script to be picked up and run at the proper time during system startup, you should save it to a file called FooBar.sh in /usr/local/etc/rc.d and make sure it is executable. You can make a shell script executable with chmod(1) as shown below:

# chmod 755 FooBar.sh

Some services expect to be invoked by inetd(8) when a connection is received on a suitable port. This is common for mail reader servers (POP and IMAP, etc.). These services are enabled by editing the file /etc/inetd.conf. See inetd(8) for details on editing this file.

Some additional system services may not be covered by the toggles in /etc/rc.conf. These are traditionally enabled by placing the command(s) to invoke them in /etc/rc.local (which does not exist by default). Note that rc.local is generally regarded as the location of last resort; if there is a better place to start a service, do it there.

It is also possible to use the cron(8) daemon to start system services. This approach has a number of advantages, not least being that because cron(8) runs these processes as the owner of the crontab, services may be started and maintained by non-root users.

This takes advantage of a feature of cron(8): the time specification may be replaced by @reboot, which will cause the job to be run when cron(8) is started shortly after system boot.