[RFC] Disabling jobs in Upstart

[James Hunt]

Hi Evan,

On 18/06/11 17:50, Evan Huus wrote:
>> 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 :)
Yes - we could end up with a lot of cruft in /etc/init/ from various programs and scripts fighting
it out :-)

And as mentioned in my original mail, we need to keep the inotify watch limit in mind: if we allowed
the format you mentioned, you've suddenly got a 1-to-many mapping for number of conf files / job.

> The problem is more that it's difficult for automated scripts to
> modify conf or override files at all without being really clever.
Agreed.

> 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.
Well, there is "initctl show-config" but it isn't deciphering all the stanzas: only start on, stop
on and emits. Added to which, the contents of the underlying files may change between invocations to
show-config.

> 
> 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.
This is an interesting idea. I had a tangentially-related discussion with Barry Warsaw at UDS who
suggested a "libupstart" library with bindings for languages such as Python (obviously of interest
to Barry :-) I think this whole idea needs further exploration and discussion.

A few thoughts which spring to mind:

1) If Upstart itself used such a library to read and parse files, we would need to ensure that it
could not be blocked when attempting to read a file to avoid locking up init.

2) It would make sense to expose such functionality over D-Bus.

However, the library cannot make write requests back to Upstart itself, since as discussed we are
generally against the idea of init/initctl writing to /etc. But that implies another D-Bus server
(daemon). Yet, such a new server would be providing Upstart functionality...?

What is convenient about such a library is that it would still work for chroot sessions and could be
made to work for user sessions too.

> 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.
Right.

> 
> 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.
Indeed. At some level, we'd need policy to protect the system.

> 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.
Yes, although I do think that if we go the libupstart route, the dumb cli frontend should write a
log somewhere showing which app/process made which change.

 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