A project I’m working on needs long running processes and I’m managing them with Upstart. It’s a fantastic tool and I can’t rave about it enough. It greatly simplifies the process of turning a script into a service.
One service depends on the RabbitMQ messaging queue server being up and running. Unfortunately, RabbitMQ uses SysV to manage the service rather than Upstart and it can be tricky to get the two to cooperate when one depends on the other. The common way to approach the problem is to remove the symlinks to the RabbitMQ SysV script from the rcX.d directories and use a custom upstart script for RabbitMQ. That solution is less than ideal because I want to leave RabbitMQ alone so I don’t cut off my upgrade path in the future.
I did some poking in the SysV file for RabbitMQ (
/etc/init.d/rabbitmq-server) and found out that they already emit signals for service actions! So if I needed an upstart job to start and stop with RabbitMQ, all I have to do is this:
start on rabbitmq-server-running stop on rabbitmq-server-stopped
Now I’m hoping that RabbitMQ eventually starts packaging an upstart script with their Debian package. Should they do that, I’d probably want to fall back to that for triggering my service. To do so, I only have to tweak things a bit:
start on (rabbitmq-server-running or started rabbitmq-server) stop on (rabbitmq-server-stopped or stopping rabbitmq-server)
Using the signals emitted by the SysV script isn’t a perfect solution, and I’ll probably want to tweak things a bit to make sure the service is up (maybe in a
pre-start exec call?). It also doesn’t emit a signal for any actions other than start and stop (including restart).
But for my purposes, this is pretty good.