On Wed, Feb 29, 2012 at 11:12:35PM +0100, Svein Seldal wrote: > 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).
You might want to take a look at what the friendly-recovery package in oneiric and precise does. It intercepts the entire startup sequence (by having upstart emit a different initial startup event instead of the usual 'startup', starts only the things it needs, and continues startup only after it exits. It includes handling for manually ensuring the filesystem is mounted (using mountall --no-events), without starting services that could be problematic later. It does start udev, but would not start dbus. > 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. If the script doesn't have to write to the filesystem and can rely on all the information being available on the root filesystem, the friendly-recovery approach might work. Since it doesn't sound like you need this to be a separate boot option, you could even do 'start on starting mountall' if you wanted. > 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. I don't think that's hacky at all, it's a standard idiom for hooking in before another job. The question is whether dbus is the right point to hook in, since you say you also want to prevent other jobs from starting and not all of those depend on dbus. On Wed, Feb 29, 2012 at 11:34:02PM +0100, Svein Seldal wrote: > start on starting dbus > task > script > # Main script here... > > if [ "$production-mode" ]; then > initctl stop -n network-manager > fi > > # Disable network-manager > end script > > This does not work, as network-manager isn't started yet. NM depends > on started dbus, which hasen't happened yet. > > Is it at all possible to tell upstart not to start a future job > without having to reload its config? Either the overrides support, or making this job 'start on starting network-manager', would do the trick. > Yes, I agree and I like this way, thanks. However (as nothing is > ever simple) this is on a Ubuntu Natty system, hence upstart 0.9.7, > so no override AFAIK. I don't know offhand if that's there or not in natty - Evan seems to have a clearer idea. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
