Very nice proposal! What follows are some of my initial reactions, not necessarily well-reasoned or complete.<br><br><div class="gmail_quote">On Fri, Jun 17, 2011 at 3:42 PM, James Hunt <span dir="ltr"><<a href="mailto:james.hunt@canonical.com" target="_blank">james.hunt@canonical.com</a>></span> wrote:<br>
<div>-snip- <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
== Shortcomings of Override Files ==<br>
<br>
* There is no programmatic Upstart interface: it requires a tool/user to<br>
manually create a ".override" file contaning the "manual" stanza (or<br>
simply appending "manual" to the ".conf" file).<br></blockquote><div> <br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
* It is too generic a facility / not "fail-safe"<br>
<br>
Any Admin/tool/pkg can manipulate ".override" files. If an Admin<br>
disables a job using a ".override" file, they might find that it has<br>
later been changed by another tool that rewrote the override. This is<br>
undesirable since the job may no longer be disabled.<br></blockquote><div> <br>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.<br>
<br>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?)<br>
<br>Still, this is basically a separate issue, to be dealt with in another thread sometime.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
* Not obvious how to determine if a job *is* enabled or disabled.<br>
<br>
It is possible though. See:<br>
<br>
<a href="http://upstart.ubuntu.com/cookbook/#determine-if-a-job-is-disabled" target="_blank">http://upstart.ubuntu.com/cookbook/#determine-if-a-job-is-disabled</a> </blockquote><div><br>Since this is a read-only activity, it should be easy to roll a smarter equivalent directly into initctl, no?<br>
<br>-snip-<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
* If we provide the ability to disable any job, the system could become<br>
unbootable very quickly.<br></blockquote><div><br>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.<br>
<br></div><div>-snip-<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
= Terminology =<br>
<br>
* "limit"<br>
<br>
Since we want to be able to disable Upstart jobs based on some<br>
condition, "disable" is rather a crude term. The word "limit" is<br>
better since it connotes the more fine-grained approach being<br>
proposed. Its antonym being "delimit" (I'd initially thought of<br>
"restrict" and "derestrict" but (,de)limit is shorter :-)<br></blockquote><div><br>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. <br>
<br>---<br><br>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.<br><br>
Cheers,<br>
Evan<br>
</div></div>