Comment 6 for bug 701576

Excerpts from Dmitrijs Ledkovs's message of 2013-11-02 23:16:07 UTC:
> At the moment we guarantee that networking & local filesystems will be available when runlevel 2 (and similar) are emitted.
> Apart from rename, what other benefits does this semantic sugar bring?
>

First, job writers shouldn't need to be boot experts, so logically named
state tracking jobs make more sense than runlevels.

Second, this provides the ability to insert things into the stream rather
than add more parallelized actions to "runlevel 2".

Cron is a particular example where it is almost always better to start
cron as late as possible.

Consider this scenario:

[mysql.conf]
start on runlevel [2345]
[cron.conf]
start on runlevel [2345]

In this scenario, mysql is starting up in parallel with cron. Cron
is _much_ faster than mysql and so starts, and immediately runs its'
@reboot jobs which include Optimizing MySQL tables. This fails because
mysql is still coming up.

Now:

[mysql.conf]
start on starting network-services
[cron.conf]
start on started network-services

The ordering is achieved. cron is not started until mysql is started,
but they didn't have to explicitly state the relationship between cron
and mysql, it just makes logical sense.

It just means being able to order things based on this mostly generic
idea that most things are network services and thus would be migrated to
use the network-services job. If that works out, we can also have other
classes of jobs like security-services and login-services. Ideally we'd
be able to hide all of the nitty gritty plumbing events in these jobs so
that the general Upstart job reads more like a human thinks.