<div class="gmail_quote">On Wed, Feb 29, 2012 at 5:12 PM, Svein Seldal <<a href="mailto:sveinse@seldal.com">sveinse@seldal.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Steve Thanks for answering.<div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> </div> 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. </blockquote><div> 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 you. Hope this makes sense, Evan [1] <a href="http://upstart.ubuntu.com/cookbook/#override-files">http://upstart.ubuntu.com/cookbook/#override-files</a> </div></div>