What are the requirements for building Upstart?

Since Upstart's primary usage will be on distributions that utilise the user-space event mechanisms only found in recent Linux kernel versions, it has been developed to take advantage of other operating system and language features that may not be available in older releases of the kernel, C library or compiler.

The recommended versions are:

• Linux 2.6.24, or later
• GCC 4.1, or later
• GNU C Library (glibc) 2.4 or later

Communication with other processes utilises the D-Bus messaging system. In order to query the availibility of the external library, the pkg-config tool is used; and in order to generate the D-Bus bindings necessary, the Python intrepreter will be used.

The recommended versions are:

• D-Bus 1.2.1, or later
• pkg-config 0.22, or later
• Python 2.5

These should all be available from the current release of any modern Linux distribution.

What tools do I need to help develop Upstart?

The standard set of GNU Build System tools (aka. the GNU Autotools), the recommended versions are:

• GNU Autoconf 2.61
• GNU Automake 1.10
• GNU Libtool 2.2.4
• GNU Gettext 0.16.1

Will Upstart replace cron, atd or anacron?

Yes. A planned feature for Upstart is the ability to generate events at a particular scheduled time, regular scheduled time or particular timed intervals.

We also plan to be able to generate timed events based on other non-timed events, for example:

15m after started apache

Building this functionality into init makes a lot of sense, since init can combine it with service supervision. You'd be able to have a service only running between particular times, or on particular days, etc.

Will Upstart replace inetd?

Maybe. While the use cases for building cron functionality into Upstart are clear, the use cases for building inetd functionality into it aren't. So far the principal reasons for doing so seem to be the perceived similarity between inet services and ordinary services, and because Apple's launchd happens to do it.

I'm not convinced that the first is true; inet services while superficially similar to ordinary ones, are actually quite different. In Upstart parlance, an inet service would be an instance job that is only running while there is a connection on a particular port with the standard input and output of that service linked to the connection.

More interesting would be the ability to only have the single apache service running while there are incoming web connections, shutting it down again should there be no connections for a particular amount of time. Some magic would be required to ensure the first connection isn't rejected, and instead held until apache starts and answers it.

I don't think this is a job for Upstart itself though, since it's not using it other than a service supervisor and the perils of adding network-listening ports to the init process are quite terrible. This would perhaps be better served by a separate process that uses libupstart to emit the appropriate events that cause the service to be started, or stopped again later, and deals with the stalling or fowarding of network connections onto it.

Will Upstart replace udev, HAL or DeviceKit?

Absolutely not. udev's job is to listen for events from the kernel emitted when the device tree changes, and HAL's job is to collate that information with its tables of attributes and expose it over D-Bus. DeviceKit allows much of the collation and table of devices to move to udev, providing a D-Bus interface to that - eventually obsoleting HAL.

None of these things should be re-implemented in Upstart, since they are already performed perfectly by these services.

Some confusion seems to arise since the messages Upstart uses to start and stop services are called "events", and udev receives a different type of "events" from the kernel.

On the other hand, udev, HAL and DeviceKit are a rich source of Upstart events; udev rules will frequently cause Upstart events to be emitted, and so will messages from HAL or DeviceKit.

Will Upstart replace acpid or apmd?

Again, no. Upstart need not concern itself with talking to the kernel to find out status information, to convert into events, when the daemons that already do it can use libupstart to emit events when certain things happen.

Provided the set of events emitted are standardised, the same set of events can be emitted by acpid, apmd, GNOME Power Manager, etc.

Will Upstart replace D-Bus?

Another source of confusion seems to concern GNOME and Freedesktop.org developers who believe that Upstart it setting out to replace their beloved D-Bus.

There is a small truthful foundation to this. Because D-Bus has worked so well for them at message passing, they've started thinking of abusing it to also perform service supervision. It already does this at the user session level, so it seems natural to also perform it at the system level.

The mechanism for doing this is to send a nonsense message to the service, so D-Bus starts the service (in theory to handle your message).

I think this is pretty damned wrong, D-Bus should not grow service supervision abilities since it's duplicating code that already has to exist elsewhere in order to supervise D-Bus, and abusing it in this manner is also wrong.

It makes far more sense to have just one daemon that is good at service supervision, and since D-Bus itself has to be supervised, it makes no sense for that daemon to be D-Bus. However it doesn't mean that the service supervision daemon cannot use D-Bus for communication.

Upstart is that service supervision daemon; instead of sending a nonsense message to a service just to have it started, send a message to the service supervisor asking for the service you want to be started.

The caveat here is where the message isn't nonsense; in that case I think it's perfectly legitimate for it to be sent to the service itself and for D-Bus to cause the service to be started because a message has arrived for it. I would argue that D-Bus should use Upstart to start and supervise the service.