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 <email address hidden> wrote:
> On Thu, Dec 30, 2010 at 8:53 AM, Scott James Remnant
> <email address hidden> 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
> <email address hidden> 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
> <email address hidden> 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.
>
>
>