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:
So this leaves me altering my ideal 'start on started postgres' to the more generic 'start on runlevel  thus:
start on runlevel  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.
Australia: 07 3103 2894
International: +61 410 545 357