[RFC] Disabling jobs in Upstart

[Dr. David Alan Gilbert]

* James Hunt (james.hunt at canonical.com) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi All,
> 
> = Caveat =
> 
> This is very much a brain dump and doesn't have all the answers - please
> comment and fill in the blanks when you spot them! :-)
> 
> = Introduction =
> 
> We are looking to provide the ability to fully disable a job.
> 
> = Rationale =
> 
> Lots of users are familiar with the old SysV way of handling jobs and
> are looking for a chkconfig-like tool to ease the transition to Upstart.
> 
> The "manual" stanza coupled with the Override facility does already
> provide this facility, but have the following shortcomings.
> 

Good - this has been a pain ever since the switch to Upstart.

> = Requirement =
> 
> A "chkconfig"-like tool [1] to allow:
> 
>  * 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.

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

> = High-Level Plan =
> 
> My thoughts at this stage are that we provide 3 new commands (note these
> are not *necessarily* initctl commands):
> 
>   * limit <job> [<expr>]
> 
>     Restrict conditions on which job <job> is started. <expr> is assumed
>     to be a subset of the "start on" condition of <job>, however if it
>     is not, this is not an error (but a warning should probably be
>     issued since the command would have no effect at that point in time.
> 
>     QUESTION: If job <job> has already been limited, what do we do:
> 
>     1. Throw an error.
>     2. Replace the existing limit with the new one.

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.

>     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

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

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

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/