RFC: 'quiesced' event?

[Clint Byrum]

Excerpts from Steve Langasek's message of 2013-03-15 15:11:38 -0700:
> Hi folks,
> 
> One of the questions people often ask about using upstart is, "How do I
> write a job to do something once the system is booted?"  And the
> counter-question in response is, "How do you define 'booted' in an
> event-driven system, where further events can happen at any point?"
> 
> I was reflecting on this question today in connection with the following
> bug:
> 
>   https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/967229
> 
> And I realized that the recent work on user sessions might offer a possible
> answer.  In the course of defining user session shutdown behavior, we *did*
> define a concept of when upstart is "done": when there are no longer any
> jobs that are "blocked" (i.e., they have a start/stop condition with an AND,
> where one half of the condition has been met but the other has not), and all
> jobs have the same goal and state (stop/waiting or start/running).  We said
> that when the user session init reaches such a state, the system has
> "quiesced", and init can take further action to forcibly shut down the
> remaining jobs and exit.
> 
> What if we were to generalize this concept, and make it a core event within
> upstart?  That is, whenever upstart reaches this state, emit a 'quiesced'
> event?
> 
> This would enable jobs with semantics like the following:
> 
>   start on runlevel [2345]
>   stop on quiesced
> 
>   pre-stop exec plymouth quit
> 
> Great care would need to be taken in constructing jobs to ensure that this
> event remains useful; for instance, anything that did 'start on runlevel
> [2345] and quiesced' would fire once, catch the next 'quiesced' event, and
> *block any further quiesced events from happening*.  But in theory, this
> seems to me like it would be a pretty powerful extension to upstart
> semantics.
> 
> Thoughts?
> 

Hi Steve.

I like this idea, though I think it needs to follow another one.

Right now starting on a signal type event, which is what runlevel is, causes
a lot of issues.

With so many things starting in parallel 'on runlevel [2345]' there is no way to
track when they are done.

We've talked in the past that there should be some abstraction here. A job that
has no process would do the trick nicely.


# job called services
start on runlevel [2345]
stop on runlevel [016]
# end job

This can be followed now. The bulk of services would then do:

start on starting services
stop on stopping services

With that, your definition of "no more blocked events" would be reached
after all of the services above start.

Also, to prevent caught quiesced event, I think we would do well to ban
it from normal packaged upstart jobs, and abstract its use away into
a job which includes instructions on how not to screw it up. This also
would allow users to get in between the quiesced event and all of the
system packaged things that use it.