Upstart was created due to fundamental limitations in existing systems. Those systems can be categorized into two types:
- System V init system
- Dependency-based init systems
It was necessary to outline the limitations of the SysV and dependency-based init systems to appreciate why Upstart is special...
Upstart is revolutionary as it recognises and was designed specifically for a dynamic system. It handles asynchronicity by emitting events. This too is revolutionary.
Upstart emits "events" which services can register an interest in. When an event -- or combination of events -- is emitted that satisfies some service's requirements, Upstart will automatically start or stop that service. If multiple jobs have the same "start on" condition, Upstart will start those jobs ''in parallel''. To be manifest: Upstart handles starting the "dependent" services itself - this is not handled by the service file itself as it is with dependency-based systems.
Further, Upstart is being guided by the ultimate arbiter of hardware devices: the kernel.
In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required. Like the best Unix software, it does this job very well. It is efficient, fast, flexible and reliable. It makes use of "helper" daemons (such as the upstart-udev-bridge and the upstart-socket-bridge) to inject new types of events into the system and react to these events. This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons.
See more at The Upstart cookbook