[RFC] Disabling jobs in Upstart

[James Hunt]

Hi Dave,

On 18/06/11 18:33, Dr. David Alan Gilbert wrote:
>>  * Jobs to be disabled in particular runlevels.
> 
> Are you sure 'runlevels' should still be the primary way of thinking
> about this? IMHO they've always been confusing.
> I'm not sure what the alternative is - something like whether
> or not they respond to a particular event?
> Then you can have sensible events - e.g. 'startingx' or 'shuttingdown'
> Such a tool could select to filter events so that a script
> no longer responded to an event it would normally trigger on.
I think that's what we're trying to achieve. Upstart (indirectly) supports runlevels...

- for LSB compliance
- to smooth the transition from SysV
  - for users (something familiar to grasp onto :)
  - for services
    - allows existing SysV scripts to be run via /etc/init/rc-sysinit.conf
    - to simplify the conversion of SysV services to Upstart jobs.

However, jobs are able to make use of whatever events are appropriate (see upstart-events(7) on
Ubuntu Natty/Oneiric). However, as discussed recently in Ubuntu, we are looking to introduce some
new events and job aliases such as "shutdown", "reboot" and "display-manager" (rather than all the
complexity in gdm.conf) to:

- make it easier to write new .conf files.
- further ease the transition from SysV.
- allow us to simplify a number of .conf files.
- avoid jobs hard-coding applications as opposed to services they wish to make use of.

> 
>>  * If we provide the ability to disable any job, the system could become
>>    unbootable very quickly.
> 
> So I think there needs to be a boot option that does something like
> ignore all these settings?
I absolutely agree. We'll ensure this happens.

> Please make it easy for scripts that ensure the state of the world;
> e.g. if you've got a script (say as part of another package or as
> maybe a site-wide configuration system) wants to ensure openssh is
> enabled and apache isn't then throwing an error if it tries
> to set the same as the current setting is painful.
Right. It sounds like the libupstart+cli idea would work here. I'm also very keen on ensuring we
have tooling to maintain system integrity and consistency (hence show-config/check-config and
init-checkconf :)

> 
>>     QUESTION: How would we handle this scenario?:
>>
>>     $ restrict cron runlevel [35]
>>     $ restrict cron runlevel RUNLEVEL=4
>>
>>     Possible outcomes:
>>
>>     1. Cron is restricted in runlevels 3+5.
>>     1. Cron is restricted in runlevel 4.
>>     1. Cron is restricted in runlevel 3, 4 and 5.
> 
> You could require explicit + and -; e.g.
>       $ restrict cron runlevel RUNLEVEL=4
>          You get 4 and only 4
>       $ restrict cron runlevel RUNLEVEL+=3,5
>          You get 3,5 and whatever you had before
>       $ restruct cron runlevel RUNLEVEL-=3,5
>          You get 3,5 removed from whatever you had
Interesting idea - noted!

> 
>>   * delimit <job>
>>
>>     Returns any current limit expression and undoes the effect of
>>     "limit".
> 
> I'd prefer one command with options.
> 
>>   * show-limit [<job> [<expr>]]
>>
>>     Show limits for all jobs or specified job.
> 
> Again I'd prefer one command - but that's a personal preference.
> (Although it should save some space).
Point taken. We'll try to limit the number of new commands introduced.

> 
>>  * Create per job files
>>
>>    In a similar fashion to the existing ".conf" and ".override" files,
>>    we could introduce "/etc/init/<job>.limit". If this file existed
>>    and was empty, the job would be fully disabled (never automatically
>>    started). However, if it contains "<condition>", that would be applied.
>>
>>    Pros:
>>     * Analog to ".conf" and ".override" so familiar to users.
> 
> I like the per-job solution; the other pro is that it's easier
> to see what's recently changed - I think that's important when
> trying to fix a broken system.
A good point.

> Actually the other pro is that it's easier to copy these files
> between sets of machines - you don't want to encourage
> people to start writing scripts that operate on one
> big config file.
> 
>>    Cons:
>>
>>     * Easy to inadvertently delete a ".limit" file maybe?
> 
> If you're deleting stuff in /etc then you can break the system
> in many ways.
Yes, in retrospect that was rather a weak "con" wasn't it :)

Regards,

James.