When Upstart was first conceived by Canonical, the prevailing system was still sysvinit, which started everything in sequence and more or less stopped after that. It did make sure that the system closed down gracefully also. This made it necessary to have other solutions for hot-plugging devices such as USB sticks and similar. The main idea from the designers was to make it event-driven, this made it easy to handle the mentioned hot-plugging events. Upstart can also run unmodified sysvinit scripts, so you can migrate to Upstart with only an install. This project is in maintenance mode only so use this post as an interesting piece. You may run into this system in old updated systems.

How does Upstart differ?

Upstart has a model of starting any available job when the event happens. Compare this to systemd, that starts processes that have all the other systems running. The main difference is that Upstart is waiting for events and systemd is coordinating dependencies. Both systems can run regular scripts and both try to start in parallel. Because the differences are so small, Upstart scripts can usually just be called with a systemd service file. They can also, both run unchanged systemV files. In fact, both look for an old systemV file structure by default. The big difference is that Upstart looks for defined events to start anything. So if you want to add your own service, you need to figure out in which context you need your service. Usually this is easy since you will want something that runs, for example, on your desktop. The desktop starts with event runlevel 5, so you set that in your script. For systemd, in contrast, this is the graphical target. In upstart, you also have other events you can use such as mounting, mounted and keyboard request. These are handled with systemd through sockets and dbus.

How do you migrate scripts?

You have all Upstart scripts in /etc/init, their names are job name with a ‘conf’ extension. The scripts are not executable, they just point to one executable or more that should be run. In any Upstart scripts, you have defined on which event the script should start and when it should stop. You should also have pre-start and post-stop entries. These will prepare the environment and clean up after execution. A sample script is below

The ‘exec’ statement says what will happen when you start it manually. The start and stop directives defines when the script will start automatically. As you can see, you can also set the directory it will run in. There are many more aspects to Upstart but you should learn how to migrate out.

For this script to work in systemd, you need to create a service file.

Here you can see that the same things happen but with other keywords. The format is simple and to the point. Instead of having runlevels, you point at which target wants your script. This highlights that systemd is all about dependency and starting things for the specific environment. Note also that the ExecStart points to a global path, it never uses a local path.

Where does it excel?

Upstart was designed, for parallel behaviour but it was also designed to be small. If you find this anywhere still it will be in embedded systems and ChromeOS. Yes, ChromeOS had it. The reason is that it was built on top if Ubuntu from the beginning, at the time when Ubuntu had upstart as the default initial system. ChromeOS has since moved on to using Gentoo as their base.

Conclusion

Upstart is an interesting topic but mainly historical. You may need it only if you run into old systems. The most common alternative on Linux is now systemd. If you have reservations regarding systemd, you should look for other minimal systems. One interesting one is the suckless, sinit. It supports three signals and you must write all scripts for it yourself, or modify the scripts from someone else. This can be an interesting exercise but is only useful if you are working on a very minimal and specialised system.