Injecting a sequential job

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20120229/a8c1b039/attachment.pgp>