The feature planned for the next release is the support of override files, which augment configuration files, so you'll be able to do:
echo manual >> /etc/init/apache.override if you prefer Scott On Mon, Jan 3, 2011 at 6:24 PM, Bryan McLellan <b...@loftninjas.org> wrote: > On Thu, Dec 30, 2010 at 8:53 AM, Scott James Remnant > <94...@bugs.launchpad.net> wrote: >> Because, believe it or not, it's not a very common use case - in the >> Debian and Ubuntu world, you're generally expected to uninstall >> services you don't need. > > Ah, but you want to use the service, you just don't want upstart to > start it on startup. There are pretty common use cases in my workday. > > 1) Clustering > > Cluster resources should obviously be installed, but should not be > started automatically, _especially_ on startup. First, the cluster > management software (pacemaker) should control if a service is running > or not to avoid resource contention. Typically this is done using the > OCF scripts, but can be configured to use sysvinit, which more and > more often on Ubuntu means its actually upstart. Further, if a passive > node has failed and the system has rebooted, you do not want the > service to start on that node until a root cause has been determined. > It is too easy for someone to [finally] get a cluster working and not > realize that the init system is going to try to start the process when > they restart. I'm just arguing that it should be simple to disable > service startup in that case. > > 2) Alternative process management > > Many people use daemontools or runit for process management of > essential services, particularly instead of sysvinit. I see that > upstart has process supervision, which is often one of the factors in > choosing a different process management package. However, aside from > familiarity and custom, there are other features of these packages, > such as logging of stdout/stderr, that prove extremely useful in > debugging services and will continue to induce their use. So we > shouldn't assume that the user wants to use the process management > tool that the package is shipped to use. > >> But as I said in my last comment, there is now an easy way to mark a >> job as manual - and in the next release, this won't even require >> editing the .conf file > > This isn't a whole lot better than simply commenting out the 'start > on' line. There should be a way to cleanly do this programmatically. > If you remove the upstart conf file, you lose the ability to test the > service "out of the box," which is an important part of > troubleshooting. Today, the Chef provider for upstart will try to > manage the service starting on system startup by [un]commenting the > 'start on' line in the .conf file. This is a bit hard to do with a > guarantee, but okay. Programmatically editing config files is hard. > Does the user manage this file, or dpkg, chef, or some combination? > > By default I am tempted to argue for a '.d' structure. There is some > irony in this since upstart puts its configs in /etc/init and using > /etc/init.d would overlap with sysvinit. I'd hate to see the custom > hacking that we get with some sysvinit scripts where they source > DAEMON_START="yes" in /etc/default/DAEMON. Something universal for > upstart needs to exist. I've put off this email too long hoping I'd > have more time to think about a solution than I have had. > > It must not require modifying the contents of a configuration file > that other packages or the user owns. > It should be simple, perhaps even simple enough that a user would use > a tool to operate the mechanism, allowing other tools to be built on > top as well. > > On Thu, Dec 30, 2010 at 11:32 AM, Scott James Remnant > <94...@bugs.launchpad.net> wrote: >> The "expected to uninstall" comes from Debian Policy, btw. It >> probably shouldn't be a surprise that Debian still to this day doesn't >> provide a canon way to disable init scripts from running on boot aside >> from uninstalling the package. > > update-rc.d comes with the sysvinit package on Debian. It works pretty > well, is accepted as the standard for package maintainer scripts and > used by most configuration management systems. There are other tools, > like sysv-rc-conf and bum, that are easy enough to install if you want > a user friendly interface. What is essential about the existence of > these tools is that there is a manageable way to control service > startup and shutdown. The link based system was a little obtuse and > required a bit of work to manage, but it has served us well. > > On Thu, Dec 30, 2010 at 4:33 PM, Scott James Remnant > <94...@bugs.launchpad.net> wrote: >> Sometimes people forget that normal users don't care one iota about >> what a service is, let alone which are running on their machine > > http://www.ubuntu.com/server > > Perhaps normal users of the desktop edition don't, but I'd reckon most > users of the server edition know what a service is, and care which are > running on their machine. Please remember that we are legitimate users > of Ubuntu, particularly when rewriting core system services. > > The lack of this feature becomes harder on us as more and more > services are converted to use upstart out of the package. For > instance, mysql-server uses upstart now. > > -- > You received this bug notification because you are a member of Upstart > Developers, which is subscribed to upstart . > https://bugs.launchpad.net/bugs/94065 > > Title: > init: add non-destructive means to disable a job > > Status in Upstart: > Triaged > Status in “upstart” package in Ubuntu: > Invalid > > Bug description: > I need the ability to disable an event.d entry without removing the entry > completely. this is the equivalent of commenting a line in /etc/inittab. > this might be to temporarily disable a serial line getty, or whatever. > > > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/94065 Title: init: add non-destructive means to disable a job -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
