On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote: > On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: > > I suspect you and I have a root disagreement over the utility of exposing > > some of those degrees of freedom to every init script author, but if you > > have some more specific examples of policy that you wanted to change but > > couldn't, I'd be interested in examples. > It's not necessarily the init script author who might want the degrees > of freedom, but the local system administrator. > The most basic is the idea that whether you can control (via shell > scrpit fragments) whether or not a service should start at all, and > what options or environments should be enabled by pasing some file. > The fact that we can put that sort of thing in configuration files > such as /etc/default/*, for example. > Yes, yes, you can do this via if you use system V init scripts scripts > in backwards compatibility mode, but you've argued that we should be > moving briskly away from that. In which case system administrators > will need to hand-edit the services files by hand, which will no doubt > increase the chances of conflicts at package upgrade time, compared to > if the configuration options were isolated away in files such as > /etc/default/rsync (for example). FYI, the recommended, simplest way to administratively disable a service in upstart is: # echo manual >> /etc/init/$service.override You can certainly do more complex checks by adding a pre-start script if you want, but for the common case of administratively disabling, the above is more than sufficient. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature