Injecting a sequential job
eapache at gmail.com
Wed Feb 29 22:29:21 UTC 2012
On Wed, Feb 29, 2012 at 5:12 PM, Svein Seldal <sveinse at seldal.com> wrote:
> Hi Steve
> Thanks for answering.
> Could you provide some more detail about what the job is that you're
>> 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
> 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.
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 , although as Steve
pointed out the Debian Policy restrictions really only apply to packages in
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...
More information about the upstart-devel