RFC: 'quiesced' event?

[James Hunt]

Hi Steve,

On 15/03/13 22:11, Steve Langasek wrote:
> 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 is a very interesting idea. When we perform the Session Init shutdown, we
force all jobs to change state so we know the expected outcome and handle the
situation accordingly. But interestingly, looking at an actual system, I'm not
seeing a point where quiesced would be emitted 'naturally'. I think therefore we
need to take a closer look at the state of the blocked jobs and events to
understand why this is.

> 
> 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?

Kind regards,

James.
--
James Hunt
____________________________________
http://upstart.ubuntu.com/cookbook
http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf