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.