On Wed, Feb 29, 2012 at 5:12 PM, Svein Seldal <[email protected]> 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 you. Hope this makes sense, Evan [1] http://upstart.ubuntu.com/cookbook/#override-files
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
