Hi Evan, On 17/06/11 21:41, Evan Huus wrote: > Very nice proposal! Thanks!
> > 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. That's my view too. > = 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). I had started out with disable/enable in mind too (if nothing else for parity with SysV terminology). However, I think the resultant behaviour is more subtle with Upstart so maybe it deserves a different name? We are considering a facility that can disable a job entirely, but which can also restrict/limit/modify/a-n-other-term-here a jobs behaviour based on one or more events being emitted. And it can disable implicitly jobs which specify the original job in their start on. However, I'd be happy with any of the names as long as the documentation is clear on the precise behaviour. Kind regards, James. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
