Upstart config for Graphite's carbon-cache daemon

carbon-cache.conf

#!/etc/init/carbon-cache.conf
description	"Carbon server"

start on filesystem or runlevel [2345]
stop on runlevel [!2345]

umask 022
expect fork
respawn

pre-start script
    test -d /opt/graphite || { stop; exit 0; }
end script

chdir /opt/graphite

# Note the use of a wrapper so we can activate our virtualenv:
exec start-stop-daemon --oknodo --chdir /opt/graphite --user graphite --chuid graphite --pidfile /opt/graphite/storage/carbon-cache-a.pid --name carbon-cache --startas /opt/graphite/bin/run-carbon-cache.sh --start start

run-carbon-cache.sh

#!/bin/sh

set -e

HOME=/opt/graphite

. /opt/graphite/.virtualenv/bin/activate
. /opt/graphite/.virtualenv/bin/postactivate

exec /opt/graphite/bin/carbon-cache.py "$@"

Thanks. Annoying that software authors are still building daemonization into their executables. This helped : )

I'm having trouble with this as strace is telling me there's 3 forks, which upstart can't handle and gets into a bad place

Use --debug to keep carbon-cache in the foreground and you will have no issues.

This script didn't work very well for us; it tends to leave pid files around and refuses to restart. We've had better luck with this one: https://github.com/captnswing/chef-graphite/blob/master/templates/default/carbon-cache-upstart.erb

I'm looking to deprecate this version in favor of @dbeckham's better version which avoids some of the craziness by running twisted with --nodaemon rather than having to fight it:

https://gist.github.com/dbeckham/8057390

(see graphite-project/carbon#144 for the actual request for first-class support in carbon-cache.py)