Comment 4 for bug 585908

This is an interesting message and I think deserves broader discussion,
so I'm CC'ing upstart-devel.

On Fri, 2011-02-04 at 19:51 +0000, Mike Bianchi wrote:
> On Fri, Feb 04, 2011 at 06:17:30PM -0000, Clint Byrum wrote:
> > As far as the assertions, I think we have a method of making sure that
> > required files are there in the packaging system. The package upstart,
> > which owns /etc/init/rc-sysinit.conf, depends on mountall and ifupdown.
> > Further, there may be situations where something starts on an event that
> > is only generated by something it is not dependent on. For instance, you
> > may only want to run task foo when a service with NEEDS_FOO=1 starts.
>
> Let me respectfully disagree in the case where files _must_ be present
> and events _must_ be asserted.
>
> If a file is accidentally removed, renamed, or becomes unaccessible _and_
> is necessary for a successful boot, I want /bin/init or whatever to scream
> loud and long. The best place for that is in the *.conf stanza that depends
> upon the event that the missing file is supposed to assert.
>

Complaining loudly is different than asserting, IMO, so I may have just
misunderstood your intent. To me upstart is as much a library as it is a
program most of the time, so asserting and stopping everything /
crashing is a lot different than warning/crying about an obviously
broken system.

I'd be pretty happy if we had something that scans upstart's jobs, and
complains during postinst of a new upstart job:

"W: event X, used by job Y, has no emits clause"

I think James Hunt's visualization tool will add the right hooks to make
this possible.

>
> > The loose coupling gained by *not* making things too rigid is I think
> > part of the power of the system.
>
> Yes. Where events are optional, then we don't want hard checks.
>
> However if there was a double check on the file existing _and_ the event
> happening, then there would be an enforced documentation of both the event
> and where it was expected to come from, as a "good programming practice".
>
> More than one source of an event? Check for the existence of at least one
> of the source files or commands.
>

Agreed on principle that having something like this will be beneficial.
I'm coming around to the idea of a keyword

start on required foo

Which would at tell upstart to check for emits after parsing all
configs, and warn about the situation.

I still question the value of enforcing this. Rather, I don't know if
there are mechanics for it. What exactly are you going to refuse to do
if there's no emitter for an event? Are you going to just start the job
anyway? That could make things *worse* by not waiting for necessary
resources. Not start or stop at all? Well thats what happens now. Exit
and panic the system? That seems a bit counter-productive to me.

>
> > The 'emits' keyword is sort of like
> > assertions, but on the other side. Right now, there's no enforcement of
> > emits, so they're prone to rotting over time.
>
> All the more reason to have a programmed means to couple the emit with the
> event's sensitivity.
>

Right, so if we at least throw warnings when nothing claims to emit
something that is started on, we have a better situation. Bugs will be
opened and fixes made to better document the emits. It even seems a
light weight enough check that it would be doable at boot time.

> -
>
> Let me say again that this whole mess makes me nervous. In the good old
> days if I could come up with a strictly sequential order of
> /etc/init.d/S[0-9][0-9]* scripts that worked reliably, I was done!
>

Its getting easier as bugs are fixed and hook points are found. One just
needs to pick a spot in the boot and start there. I agree that the value
of the /etc/rc2.d dir is that you can look at it as a whole, where as
with upstart currently its hard to know what events are available and
what starts or stops when.

That said, the bug to document events seeks to make this quite a bit
easier to understand, so hopefully your concerns will be addressed.

> It would work every time because A would be followed by B etc. all the way
> down to the end. Getting the strict relationship of all events and all
> dependencies correct is (for now) proving to be non-trivial.
>
> I suggest once more that having the _option_ of having a strictly sequential
> boot sequence for those of us that are not sensitive to how long it takes
> the machine to boot is _very_ desirable.
>

I'm not sure this is doable with upstart alone. How are you going to
define the order when 15 things start on one event (runlevel 2 for
instance)?

The situation that is difficult is the one where multiple things use a
service and its not clear how to block all of them and make sure that
job has started. I think we have a solution for that now, so hopefully
the confusion there will go away.

Also, whenever the state rewrite is finished, and we can just say what
state you want to run a service in, I think people will be complaining
about how rcX.d scripts are difficult to use because you have to get the
ordering just right. Whats easier to understand..

update-rc.d foo start 20 2 3 4 5 . stop 20 0 1 6 .

or

while networking and filesystems and running slapd

?