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 <[email protected]>wrote: -snip- > == Shortcomings of Override Files == > > * There is no programmatic Upstart interface: it requires a tool/user to > manually create a ".override" file contaning the "manual" stanza (or > simply appending "manual" to the ".conf" file). > I'm firmly committed to the idea that init and initctl should not be modifying anything in /etc/init - if such a tool would be convenient or necessary, then a separate utility should be created. Safer for everybody that way. * 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. * Not obvious how to determine if a job *is* enabled or disabled. > > It is possible though. See: > > http://upstart.ubuntu.com/cookbook/#determine-if-a-job-is-disabled Since this is a read-only activity, it should be easy to roll a smarter equivalent directly into initctl, no? -snip- * If we provide the ability to disable any job, the system could become > unbootable very quickly. > The same is true of SysV-style init. Whatever tool we provide to actually do the disabling should throw up big warnings for certain jobs of course, but architecturally not our problem. -snip- > = Terminology = > > * "limit" > > Since we want to be able to disable Upstart jobs based on some > condition, "disable" is rather a crude term. The word "limit" is > better since it connotes the more fine-grained approach being > proposed. Its antonym being "delimit" (I'd initially thought of > "restrict" and "derestrict" but (,de)limit is shorter :-) > I disagree. To me, limit means not fully disabled, as in still partially functional. I would suggest stanza 'disable' (like manual, except cannot even be started manually). Also stanza 'disable on condition' where condition takes the same form as start on or stop on. Whenever a 'disable on' stanza is read, its conditions are subtracted from any existing 'start on' conditions. --- I have more to say, but it will have to wait until I have time to sort through my thoughts a little more. There are a lot of interesting problems here, and a lot of good solutions already proposed. Cheers, Evan
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
