Upstart jobs that depend upon non upstart jobs

Upstart is wonderful. It is a clear, concise and robust way to ensure that processes get launched in the right way on a Linux server.

However, many older Linux applications do not come with upstart process control by default. instead they use the old SysV initialisation or some such. This is generally fine until the time comes when you have an upstart job that needs to depend upon an older job. A perfect example of this is PostgreSQL. When I have a django project that needs to run as a process, my upstart job would naturally start with:

start on started postgres
stop on stopped postgres
...

This is nice but unfortunately it doesn't work because postgres is not handled by upstart so the started and stopped events are never emitted.

The obvious options to solve this problem are to:

Fix postgres
This is not hard but it worries me that updates will overwrite my changes or clash with my solution... unless I submit the contribution to postgres, and that is too hard right now.
Use supervisor
This will manage our processes instead of upstart and will keep trying to start them so that when they crash if postgres is not running it will just keep trying them until it works. Meh... kludgy.
Use a timeout
Put my service start to sleep for long enough to be reasonably confident that postgres will have started. This is just horrid.
Find an upstart event that is emitted reliably after postgres has started
Events for the runlevel are emitted and postgres works under runlevels 2..5. Thus if we start our upstart job after the relevant runlevel has started we should be good to go (this is still potentially somewhat inefficient because it serializes our startup to all of the relevant runlevel jobs but it is probably the best we can do.

So this leaves me altering my ideal 'start on started postgres' to the more generic 'start on runlevel [2345] thus:

start on runlevel [2345]
stop on runlevel [!2345]
...

This ensures that the process sorta starts and stops at an appropriate time. It is not ideal because if I were to stop the postgres service, it will not stop the associated services and if I restart the service it does not restart the associated services but it will suffice until Debian/Ubuntu Postgres configurations catch up to the benefits of using upstart.


Comments

There are currently no comments

New Comment

required

required (not published)

optional

Australia: 07 3103 2894

International: +61 410 545 357