Injecting a sequential job

Evan Huus eapache at
Wed Feb 29 22:29:21 UTC 2012

On Wed, Feb 29, 2012 at 5:12 PM, Svein Seldal <sveinse at> wrote:

> Hi Steve
> Thanks for answering.
>  Could you provide some more detail about what the job is that you're
>> trying
>> to run?  There's probably a solution that lets you achieve your end goal,
>> but would need to know what that end goal is to provide useful guidance
>> here.
> Yes sure. A bit complex I'd amit. I hope you can bear with me:
> Its an embedded product which has two distinct modes to run in: production
> mode and normal application mode. Application mode is standard rc runlevel
> as on a normal desktop installation. The production mode is a special mode
> used in production where no normal services should start except a few
> handpicked ones (static eth0, ssh).
> The decision between prod.mode is done from a script. I've been
> experimenting with starting this as a job task. One of the purposes in
> production mode is to have a very specific network setting and publish this
> on avahi.
> In app mode network manager provides the user's network configuration. One
> of the challenges I'm facing is how to handle network manager in production
> mode. NM holds the user's config and not the network setup needed in
> production mode. NM starts very early (even before any net-device-up is
> emitted), thus I'm experiencing a race between my script and NM.
> I've been experimenting with "start on starting dbus" (which is a common
> denominator between nm and avahi) to be able to stop nm and set the network
> manually when going to prod.mode. Yet this has a hacky feel to it. This
> script is vital for the product, so it needs to be simple. Complex rules
> will fail.

Hi Svein,

Wiser heads than mine might have better or different suggestions, but
here's how I would solve this problem:

Have your 'choose-mode' job start on filesystem, then have it emit one of
two events (either 'production-mode' or 'application-mode' depending).
Change all the other jobs that you wish to delay to also start on the
appropriate mode. You can do this without touching the *.conf files by
using *.override files as described in the cookbook [1], although as Steve
pointed out the Debian Policy restrictions really only apply to packages in
the repository.

Also as Steve noted, delaying udev or networking is dangerous because
non-root filesystems won't necessarily be available. As this is an embedded
system (with likely only one, local fs) that's probably not a problem for

Hope this makes sense,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the upstart-devel mailing list