Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a perfectly good script for use in /etc/init.d. In fact, I have a lot of them, all created with the Tanuki Java Service Wrapper.

It would seem to me that there could be a simple template for wrapping such a shell script up as an upstart script, but a bit of googling is not revealing one.

Am I missing something?

share|improve this question
up vote 9 down vote accepted

I don't recall seeing a template for this. Its a bit ironic, however, that technically, its upstart that is starting your init.d script in the first place thanks to the backward compatibility job rc and rcS.

I would consider rewriting whatever you have as an upstart job, however, I know that some scripts are difficult to convert, so here's what I did for a while on some of my scripts:

description "xyz"
author "xyz"
start on runlevel 5
stop on runlevel [!5]

pre-start script
    # do my work here to start the service
end script

post-stop script
    # do work here to stop the service
end script

Now depending on the nature of the service, whether it persists or forks itself, you may need to add expect fork or task to the job file.

Just to complete the thought, usually, this is all there is to a full upstart job file anyway. All of the pre start work is done, all of the cleanup is done, the only thing remaining is the service itself which is usually added with:

exec service_cmd
share|improve this answer
In upstart, the documentation says that run levels 3,4, and 5 are unused. So, you just should use run level 2. – djangofan Dec 20 '11 at 16:27

So one point of upstart jobs is to be simple to write.

There's a lot of shell script magic in init.d scripts that gets repeated over and over. Case statements, pidfile tracking, lsb comment lines. Its not very clear how to write a GOOD init.d script without having read one.

If you've already gone through the trouble of writing all of that, then you don't need an upstart job unless, as I mentioned in another comment, you depend on another upstart job/event.

But really, upstart does make things really simple. You shouldn't need a pre-start unless you need to set things up like tmpdirs, ulimits, or runtime arguments. You shouldn't need a post-stop unless you want to make sure you tidy up after a service (the service really should be cleaning up after itself on normal exit).

Often times a giant init.d script with many options boils down to a 10 - 15 line upstart job. The most complex init.d scripts can have most of their logic dumped into pre-start's. The key there is that its just a little snippet of code to setup the environment for the process, and not logic on handling start/stop/respawn/etc.

The hardest part, and the one that people get wrong the most often, is knowing when to start/stop their job. start on runlevel [2345] seems logical, but ignores the fact that the network is coming up in parallel at that point, as are local filesystem mounts. The key is to try and figure out exactly the minimum things you need (other services, filesystems, network, etc) to get running, and start when those are done. Most traditional network services should do start on (local-filesystems and net-device-up IFACE!=lo).

share|improve this answer

I thought that Upstart maintains backward-compatibility with SysV-style init scripts in /etc/init.d. You should be able to just use your init scripts unchanged.

share|improve this answer
It does, but the order is no longer so easy to predict. Upstart jobs may be starting before/after your rc2.d/S99mything script is running. So as soon as you depend on an upstart managed service, you need an upstart job. – SpamapS Nov 27 '10 at 22:17
As a hack, you could remove your init scripts from specific runlevels, and instead add a bunch of lines like /etc/init.d/myservice start to /etc/rc.local, in the correct order. This will ensure that your services start up last, after all other services, including those started by Upstart init scripts. – Ryan Thompson Nov 29 '10 at 0:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.