<OK> [Bug 585908] Re: cross-comment events and *.conf files

[Scott James Remnant]

So one interesting thing about this is that if you design a system
that complains about its configuration during boot, then you're
complaining at the wrong person, the user.  The user has no idea how
the system boots, and should have no need to know.

The system should boot regardless, and it _should_ be possible to
design an Upstart boot sequence such that even if certain things don't
happen, other things happen instead.  We obviously haven't done that
yet.

That being said, I'm all for an external tool to verify a
configuration, which operating systems could run as part of release
testing, etc.  Distributions like Ubuntu could run it after an upgrade
to check for errors, and rollback the upgrade if the resulting
configuration would not boot.

Scott

On Fri, Feb 4, 2011 at 1:02 PM, Clint Byrum <clint at ubuntu.com> wrote:
> 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
>
> ?
>
>
>
> --
> upstart-devel mailing list
> upstart-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
>