[RFC] Disabling jobs in Upstart

[Evan Huus]

Very nice proposal! What follows are some of my initial reactions, not
necessarily well-reasoned or complete.

On Fri, Jun 17, 2011 at 3:42 PM, James Hunt <james.hunt at canonical.com>wrote:
-snip-

> == Shortcomings of Override Files ==
>
>  * There is no programmatic Upstart interface: it requires a tool/user to
>   manually create a ".override" file contaning the "manual" stanza (or
>   simply appending "manual" to the ".conf" file).
>

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.

 * It is too generic a facility / not "fail-safe"
>
>   Any Admin/tool/pkg can manipulate ".override" files. If an Admin
>   disables a job using a ".override" file, they might find that it has
>   later been changed by another tool that rewrote the override. This is
>   undesirable since the job may no longer be disabled.
>

This is a short-coming of override files that should be fixed regardless of
how upstart eventually ends up handling job disablement: if two automated
scripts want to override a job file in non-conflicting ways, then they
currently can't without being really clever.

A very quick sketch solution would be allowing multiple
"job.override.overriding_program_or_user" files as override files. If two
such files try and override the same stanza, upstart throws a big fat
warning and completely ignores all stanzas from all override files
(assumption that the default job config is sane without any overrides?)

Still, this is basically a separate issue, to be dealt with in another
thread sometime.

 * Not obvious how to determine if a job *is* enabled or disabled.
>
>   It is possible though. See:
>
>   http://upstart.ubuntu.com/cookbook/#determine-if-a-job-is-disabled


Since this is a read-only activity, it should be easy to roll a smarter
equivalent directly into initctl, no?

-snip-

  * If we provide the ability to disable any job, the system could become
>   unbootable very quickly.
>

The same is true of SysV-style init. Whatever tool we provide to actually do
the disabling should throw up big warnings for certain jobs of course, but
architecturally not our problem.

-snip-


> = 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). Also stanza 'disable on condition' where
condition takes the same form as start on or stop on. Whenever a 'disable
on' stanza is read, its conditions are subtracted from any existing 'start
on' conditions.

---

I have more to say, but it will have to wait until I have time to sort
through my thoughts a little more. There are a lot of interesting problems
here, and a lot of good solutions already proposed.

Cheers,
Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20110617/ca7147c5/attachment-0001.html>