[RFC] Disabling jobs in Upstart

[Evan Huus]

Okay, so here's some more, probably all of it :)

On Fri, Jun 17, 2011 at 4:41 PM, Evan Huus <eapache at gmail.com> wrote:
> 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-
>>  * 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.

In retrospect, this seems like a bad idea :)

The problem is more that it's difficult for automated scripts to
modify conf or override files at all without being really clever.
Sure, it's easy to hard-code a string to append to the end of a file,
but there is no easy way that I'm aware of for another program to
intelligently inspect an upstart or override file and make decisions
based on that without writing its own parser.

One solution would be to split the parse_job bits out into a separate
libupstart-jobfile or similar and add a 'save' or 'write' method.
Theoretically a program should be able to link with the lib, call
parse_jobfile(name), modify the returned object, and then save it,
with the library guaranteeing that the written job file is at least
grammatically sane. A dumb cli frontend would make it easy for scripts
and users to do the same.

Back to how this applies to the original comment: SysV didn't prevent
automated scripts from overriding user choices in this fashion either,
it just made it easy for scripts to do what they wanted without
*accidentally* overriding user choices. Hopefully a libupstart-jobfile
would solve that problem.

---

Given some sort of solution to the above, then it is clearly no longer
necessary for separate job.limit files or a separate /etc/init.limits
or anything along those lines - it should be safe and easy for
multiple scripts/users to put everything they want into one
job.override file. The question then becomes what stanza should be
used, and how it should be handled. While I still prefer the term
'disable' to 'limit', everything else that's already been proposed
makes good sense to me.

Cheers,
Evan