We are also using upstart and are quite happy with it. But I agree, it would be nice if it had some mechanism to allow us to describe jobs and EXTERNAL to that, persist which jobs are preferred by the user to be running.
I think perhaps the state of the jobs could be persisted and restored on reboot (as an option). If someone did a 'upstart stop-persistently sendmail' then upstart would know to not just stop sendmail for the time being but also know that this request is recorded for future reboots of the system. Likewise a 'upstart start-persistently' clause could reverse this. If these selections were recorded in a well-defined format, then installers could update the file to reflect system configuration changes without tampering with the jobs scripts themselves. This is much like the notion of symlinks in the /etc/rc.d/ filesystem for various run levels (but much better since upstart handles much more than those scripts do). Thanks for upstart... it is a very useful engine already... and we are hoping to help make it even better! Charlie On Nov 7, 2008, at 8:06 AM, Michael Biebl wrote: > 2008/11/7 Scott James Remnant <[EMAIL PROTECTED]>: >> In the 0.10 design, this is supported by adding a stanza like >> "manual" or "disabled" to the job - or removing one like "auto" >> (not yet decided) > > Where is this information stored? In the job file itself? > This imho would be a disadvantage to an external state/profile file, > as on package upgrades (at least on Debian and I guess rpm-based > distros too), you'd get prompts from the package management system. > > Cheers, > Michael > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > -- > upstart-devel mailing list > upstart-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
