Upstart should provide a generic network-services job for non-boot-critical network services to follow.

[Clint Byrum]

Binary package hint: upstart

This is a feature request for the Ubuntu upstart package.

I posted the original description here:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032254.html

The summary is that rather than require all upstart jobs to know when exactly in the boot they want to start on and when exactly in the shutdown they want to stop on, we should provide a readable, common sense job whose started/stopping events can be followed, and whose starting/stopped events can be used to prime and cleanup the environment.

A merge proposal will follow the filing of this bug report.

[Dave Walker (davewalker)]

@Clint, are you looking to try and drive this into Natty?

Thanks.

[Clint Byrum (clint-fewbar)]

This is a feature, and would require a FFe. We've already pushed it quite a bit with upstart, I think we'll save this for oneiric. James Hunt and I will be having a couple of sessions and I think a round-up of generic jobs like this will be at least part of one.

Given that I've discussed this with Keybuk a few times and he has agreed its a good idea, I'll go ahead and mark it as Confirmed/Wishlist.

[Steve Langasek (vorlon)]

Clint, is this the 'static-network-up' job in oneiric, or is something else needed still?

[Clint Byrum (clint-fewbar)]

Excerpts from Steve Langasek's message of Tue Oct 04 00:02:17 UTC 2011:
> Clint, is this the 'static-network-up' job in oneiric, or is something
> else needed still?
>

I would like to have an empty "meta" job that all other things follow,
so instead of

start on runlevel [2345]
stop on runlevel [!2345]

Which ties to sysvinit and doesn't obviously reflect the authors
intentions, we'd have

start on starting network-services
stop on stopping network-services

This would probably just have the runlevel start on / stop on listed
above.

[Dimitri John Ledkov (xnox)]

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?

[Clint Byrum (clint-fewbar)]

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.