[RFC] Disabling jobs in Upstart

[Evan Huus]

On Tue, Jun 21, 2011 at 8:37 AM, James Hunt <james.hunt at ubuntu.com> wrote:
> Hi Evan,
>
> On 17/06/11 21:41, Evan Huus wrote:
>> Very nice proposal!
> Thanks!
>
>>
>> I'm firmly committed to the idea that init and initctl should not be modifying anything in /etc/init
>> - if such a tool would be convenient or necessary, then a separate utility should be created. Safer
>> for everybody that way.
> That's my view too.
>
>>     = Terminology =
>>
>>     * "limit"
>>
>>      Since we want to be able to disable Upstart jobs based on some
>>      condition, "disable" is rather a crude term. The word "limit" is
>>      better since it connotes the more fine-grained approach being
>>      proposed. Its antonym being "delimit" (I'd initially thought of
>>      "restrict" and "derestrict" but (,de)limit is shorter :-)
>>
>>
>> I disagree. To me, limit means not fully disabled, as in still partially functional. I would suggest
>> stanza 'disable' (like manual, except cannot even be started manually).
> I had started out with disable/enable in mind too (if nothing else for parity with SysV
> terminology). However, I think the resultant behaviour is more subtle with Upstart so maybe it
> deserves a different name?
>
> We are considering a facility that can disable a job entirely, but which can also
> restrict/limit/modify/a-n-other-term-here a jobs behaviour based on one or more events being
> emitted. And it can disable implicitly jobs which specify the original job in their start on.
>
> However, I'd be happy with any of the names as long as the documentation is clear on the precise
> behaviour.

You're right that 'disable' doesn't fit well with the subtlety of the
currently proposed implementation. I'm still not happy with 'limit'
though, for reasons stated previously. How about 'block' instead?

--- 15 minutes of reflection later ---

My first though was that 'block' is just a better word for the same
sort of stanza as you were proposing for 'limit', however I feel it
could actually do with a slightly different syntax / implementation.
Hopefully this would still accomplish the same high-level goal.

The block stanza does what you might expect: it allows you to block
signals/events. A job containing "block runlevel" in it's override
file would simply never receive the runlevel event - upstart would try
to deliver it and then realize that it's blocked for that job. Syntax
for multiple blocks would be simpler than for 'start on' or 'stop on'
because there is no need for and/or logic differentiation: block
simply takes a flat list of signals (and optional parameters such as
runlevel [34]), all of which are blocked from being delivered to the
job.

Example:
conf file contains: start on runlevel [345]
override file contains: block runlevel [34]
result: runlevel [5] is still delivered, allowing the job to start
only on that runlevel event

To me, this seems much easier to conceptualize then any of the
previous stanza proposals, and we don't end up with all the confusing
corner cases that you listed in your original RFC. I'm not 100% sure
that it's capable of covering all of the use cases that 'limit' was
originally designed for, but it does cover most of them. Also of note,
with this implementation " manual " could be deprecated in favour of "
block * " or " block all ".

--- Another 15 minutes of reflection later ---

One of the cases this doesn't cover is a 'full disable' such that a
job cannot be started, even manually. 'Block' is clearly not the right
stanza for this, but 'disable' (with no parameters) is. I know it
means adding two stanzas instead of one, but they really are covering
considerably different cases, and the 'disable' stanza in this case is
exceptionally simple.

Also as an unintended bonus, I believe this neatly solves the problem
of being able to block/disable/limit specific instances of a job
(originally planned for revision 2). For example, take
network-interface.conf on my Ubuntu Oneiric system. Adding "block
net-device-added INTERFACE=eth0" to network-interface.override would
theoretically disable only the eth0 instance of that job.

Thoughts, concerns?

Cheers,
Evan