[RFC] Disabling jobs in Upstart

[Evan Huus]

On Tue, Jun 21, 2011 at 9:31 AM, James Hunt <james.hunt at ubuntu.com> wrote:
> 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.

I'm not too familiar with the intricacies of file IO here. How weird
would it be for user-space authors if the library provided only
init-safe file access? How hard/complex would it be for the library to
provide both types of IO?

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

Why?

The two primary use cases I was envisioning for this was within
upstart itself, where it probably makes the most sense to link it in
statically at compile time, and for debian pre/post-install/remove
scripts, which would be using the dumb cli frontend.

Sure, exposing it over D-Bus would be nice for other programs too lazy
to link it in themselves, but it isn't actually necessary, and it
comes with a whole slew of interesting side-problems as you've already
mentioned.

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

Confused slightly here. If we link in the library, then it's just a
matter of making sure we don't call the library's 'write' or 'save'
method anywhere within upstart, no?

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

My initial thought was even simpler than that: the library should just
take a path name (/etc/init or ~/.init or whatever) and a job name and
not care about chroots or anything complicated like that. It could
even be used for manipulating job files in a temporary working
directory this way, or on a partition mounted somewhere else on the
filesystem. The library shouldn't care if it's working in /etc/init or
not.

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

tl;dr - I agree

Massive tangent:

It should be specifiable (in /etc/init.conf) a 'system happy' job
(such as perhaps gdm or the new display-manager alias) such that
upstart knows the system has booted relatively successfully if that
job is running successfully.

Whenever the system boots successfully, upstart (or a related daemon)
copies the contents of /etc/init/ to /etc/init.known_good/.

Whenever the system fails to boot successfully (No new jobs started
within timer limit even though target happy job not running?) upstart
reboots (re-execs?) and boots with /etc/init.known_good/ instead.

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

Agreed

Cheers,
Evan