init: add non-destructive means to disable a job

I'm in need of a disable method as well.

is there a disable method yet? i reported this initially over a year ago. (there may be, but since there's no upstart manpage on hardy, it's hard to know. :-)

Does this bug report say that there is a disable method? Is it marked Fix Released?

No.

The plan in 0.10 is that jobs will be in "automatic" mode by default, and can be placed into "manual" mode when necessary.

"manual" mode means that the job will still show up in lists, and new instances will still be created as necessary, but they will not be automatically started by Upstart.

A sysadmin may still use "start" to start them though (always do what the SA says)

We'll want an additional "upgrade" mode as well; a package should be able to place a job in upgrade mode for the period that it is replacing the software. We actually need to be able to place a job in upgrade mode before we create the configuration, which is somewhat interesting ;)

This feature is essential before we start moving certain services over to upstart.

A example is to be able to start a server running mysql as a slave without mysql starting automatically, as we would need to verify binary log position between the servers first.

Installing memcached, but running multiple instances via separate upstart files would allow one to remove the default file, but a package upgrade could replace the missing file, so one would have to edit it, which could cause an unnecessary packaging conflict on upgrade.

Being able to script the these settings is required. The above plan sounds perfect, except that it is not implemented yet.

Earlier discussion of the above plan: http://<email address hidden>/msg00638.html

For sanity's sake, I'm closing the Ubuntu tasks for upstream Upstart bugs. I've experimented with having both, but it is just making bugs hard to find now. Will use the policy whereby bugs on the Ubuntu package exist in the Ubuntu packaging or patches only, any bugs in the Upstart code are Upstream bugs.

where can i find the upstream bug?

On Wed, 2010-04-07 at 16:27 +0000, paul fox wrote:

> where can i find the upstream bug?
>
This is the upstream bug ;-)

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

sorry. clearly i didn't parse the status change attached to comment #6 correctly. i thought it was this bug that had been marked invalid.

Paul, Launchpad allows a single bug to be tracked in multiple places. When the upstream bug tracker is supported by launchpad we can track both the progress fixing the bug upstream, and the progress getting that fix into Ubuntu as these don't happen simultaneously. Scott uses launchpad to track 'upstream' bugs for upstart, the bug line with (Ubuntu) in it is a bug filed in the Ubuntu distribution, where as the bug line without is filed against the launchpad project for upstart itself.

Scott, will this policy set the upstart bug to fixed when it is committed to bzr or when it is fixed in an Ubuntu release? How will we tell when the other happens?

On Wed, 2010-04-07 at 17:47 +0000, Bryan McLellan wrote:

> Scott, will this policy set the upstart bug to fixed when it is
> committed to bzr or when it is fixed in an Ubuntu release? How will we
> tell when the other happens?
>
Fix Released when a new upstream release of Upstart is made; which I
package and upload to Ubuntu as I make it ;-)

Scott
--
Scott James Remnant
<email address hidden>

Sounds like this functionality could be provided by implementing the Profiles blueprint [1]?

[1] https://blueprints.launchpad.net/upstart/+spec/profiles

Is there any recommended workaround?

Crazy as it may seem to replace the init system with one lacking this most basic of functionality: no - there doesn't appear to be any workaround.

If you comment out (#) the "start on" line, it effectively disables the job while still making it available to start manually. This also ensures that dpkg still sees it on upgrades and your changes aren't overwritten. Not completely non-destructive, but it works.

Thanks, that will work for me.

@sPOiDar: This missing feature is not actually required for upstart to do its job. It is, of course, very nice to have.

On 14/09/10 02:40, Sergey Svishchev wrote:
> @sPOiDar: This missing feature is not actually required for upstart to
> do its job. It is, of course, very nice to have.
>

Upstart is an init system - being able to control which services are
started on boot on a host is core functionality, particularly when
services like mysql are already migrated to it. This may not be very
important on your desktop machine, but in a server it's quite necessary.

In VM environments, for example, memory is a precious commodity so
running numerous extraneous processes is extremely undesirable. A more
serious example of why this is important - any cluster/HA environment
needs to have services under tight control for correct, reliable
operation. Starting them out of order, or when they're meant to be down
can lead to some quite nasty results, and a lot of manual intervention
to repair. The lack of this feature means manually hacking the scripts,
then carefully dealing with every upgrade - it's a shambles.

It's these sort of decision that make me re-evaluate whether Ubuntu has
actually matured enough for the server, or whether the strong desktop
focus obscures the view of what's important in the server space.

When does this spec https://launchpad.net/upstart/+spec/profiles will be added to upstart ?

it is slightly embarassinng to not have a simple tool or a command line to disable jobs at startup.
I'm really suprised such simple thing was not added from the beginning.

Note that in Upstart 0.6.7, you can disable a job with:

  echo manual >> /etc/init/JOB.conf

(this bug isn't completely fixed yet, because we want to allow a
method to do that without modifying the original file)

On Wed, Dec 29, 2010 at 10:59 PM, plouf <email address hidden> wrote:
> When does this spec https://launchpad.net/upstart/+spec/profiles will be
> added to upstart ?
>
> it is slightly embarassinng to not have a simple tool or a command line to disable jobs at startup.
> I'm really suprised such simple thing was not added from the beginning.
>
> --
> 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.
>
>
>

"slightly embarassinng"? Youre being very kind...

Its a complete shame for Upstart not to have ANY means to disable services at startup.

More incredibly is that Ubuntu (and even Debian) is now migrating to it.

So now we are back to the old days of manually editing scripts? Hows that ANY improvement? Not everyday a tool achieves being bad for both desktop end users AND server sysadmins...

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.

Also the Dpkg package manager *honours* deletes as a conffile change,
so if you simply delete the job (or change its extension) it won't
come back after an upgrade.

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

Scott

On Thu, Dec 30, 2010 at 7:32 AM, MestreLion <email address hidden> wrote:
> "slightly embarassinng"? Youre being very kind...
>
> Its a complete shame for Upstart not to have ANY means to disable
> services at startup.
>
> More incredibly is that Ubuntu (and even Debian) is now migrating to it.
>
> So now we are back to the old days of manually editing scripts? Hows
> that ANY improvement? Not everyday a tool achieves being bad for both
> desktop end users AND server sysadmins...
>
> --
> 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.
>
>
>

"expected to uninstall?" says who? as the original submitter of this bug, let me be the one to point out this phrase from the description: "this might be to temporarily disable a serial line getty, or whatever." that doesn't sound like a reason to uninstall to me.

in any case, i think this bug has been fixed for some time: you can already comment out the "start" line, or, apparently, add a "manual" line. and if the (dumb, in my opinion) requirement for using a .conf suffix (why are we trying to reinvent DOS?) is fully implemented, then renaming the file to "myservice.disabled" should accomplish the same thing.

Indeed, all of those things work.

The reason for the ".conf" suffix is because editors frequently write
temporary working files into the same directory as the original file,
they also write backup files, and package managers frequently write
"old or new" files into the directory as well.

You end up with a huge amount of filter code to exclude "FILE.bak"
"FILE~" "#FILE#' "FILE.dpkg-new" "FILE.dpkg-old" "FILE.rpm-tmp" etc.
And every time a new editor or package manager gets invented, you have
to run to catch up.

Thus it was decided amongst the group of developers working on
plumbing-layer tools to use extensions.

Scott

On Thu, Dec 30, 2010 at 5:20 PM, paul fox
<email address hidden> wrote:
>
> "expected to uninstall?"  says who?  as the original submitter of this bug, let me be the one to point out this phrase from the description:  "this might be to temporarily disable a serial line getty, or whatever."  that doesn't sound like a reason to uninstall to me.
>
> in any case, i think this bug has been fixed for some time:  you can
> already comment out the "start" line, or, apparently, add a "manual"
> line.  and if the (dumb, in my opinion) requirement for using a .conf
> suffix (why are we trying to reinvent DOS?) is fully implemented, then
> renaming the file to "myservice.disabled" should accomplish the same
> thing.
>
> --
> 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.
>
>
>

fair enough.

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.

On Thu, Dec 30, 2010 at 5:49 PM, paul fox
<email address hidden> wrote:
> fair enough.
>
> --
> 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.
>
>
>

"it's not a very common use case"

I wanted to desactivate avahi-daemon without uninstalling it.

I think ubuntu is generally use by desktop users.
A new user who want to optimize the computer ressource want to disable service he don't use every day without taking the risk to uninstall it.

Today there is no easy way to do it.
Sometimes we forget that normal users like "easy to use" graphical interface and for them editing files is not a solution.
That is why I think it is a big issue.
But if it get solved in the next release. It's Fine !

Sometimes people forget that normal users don't care one iota about
what a service is, let alone which are running on their machine

On Fri, Dec 31, 2010 at 12:20 AM, plouf <email address hidden> wrote:
> "it's not a very common use case"
>
> I wanted to desactivate avahi-daemon without uninstalling it.
>
> I think ubuntu is generally use by desktop users.
> A new user who want to optimize the computer ressource want to disable service he  don't use every day without taking the risk to uninstall it.
>
> Today there is no easy  way to do it.
> Sometimes we forget that normal users like "easy to use" graphical interface and for them editing files is not a solution.
> That is why I think it is a big issue.
> But if it get solved in the next release. It's Fine !
>
> --
> 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.
>
>
>

Sometimes users forget that some developers are assholes that don't care about how they wish to use the software.

Do you often find that calling someone an asshole means they're more
likely do something you want? I must try that sometime ;-)

On Fri, Dec 31, 2010 at 4:36 AM, mikegrb <email address hidden> wrote:
> Sometimes users forget that some developers are assholes that don't care
> about how they wish to use the software.
>
> --
> 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.
>
>
>

No, my aim is to warn other users not to waste their time.

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...

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 ...

On Mon, Jan 3, 2011 at 10:58 AM, Scott James Remnant
<email address hidden> wrote:
> 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

I think that is a smart choice provided we are cautious about the
frequency that this gets leveraged.

I would expect the following cases to be true:

1) override
apache.conf: start on runlevel [45]
apache.override: start on runlevel [2345]
result: start on runlevel [2345]

2) manual
apache.conf: start on runlevel [45]
apache.override: manual
result: upstart does not control the service

3) scripts
apache.conf: pre-start script \ #blahblahblah
apache.override: pre-start script \ #foofoofoo
result: ONLY pre-start script \ #foofoofoo

Which is to stay, I would expect each stanza to act as an object that
you could overwrite from the override file to avoid having to change
the upstream configuration. Override files would never be part of a
package as a rule, and thus could be fully owner by a user. Still, an
external script or a configuration management system, would have to
edit this file to start or stop a service. This is less than ideal,
but solves the concerns about conflicting with packaging. Besides,
this file should be nonexistent in the majority of cases.

In my scenarios, having the existence of /etc/init/apache.manual
trigger upstart to not automatically start or stop the service, but
allow it to be manually started by the user, would be preferred. I
recognize upstart is driven by the characteristics of desktop services
and this could come off as configuration file cruft in those use
cases. This would be preferable for developers to invoke a permanent
programmatic change from a script.

That's the exact plan, yes

On Mon, Jan 3, 2011 at 9:08 PM, Bryan McLellan <email address hidden> wrote:
> On Mon, Jan 3, 2011 at 10:58 AM, Scott James Remnant
> <email address hidden> wrote:
>> 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
>
> I think that is a smart choice provided we are cautious about the
> frequency that this gets leveraged.
>
> I would expect the following cases to be true:
>
> 1) override
> apache.conf: start on runlevel [45]
> apache.override: start on runlevel [2345]
> result: start on runlevel [2345]
>
> 2) manual
> apache.conf: start on runlevel [45]
> apache.override: manual
> result: upstart does not control the service
>
> 3) scripts
> apache.conf: pre-start script \ #blahblahblah
> apache.override: pre-start script \ #foofoofoo
> result: ONLY pre-start script \ #foofoofoo
>
> Which is to stay, I would expect each stanza to act as an object that
> you could overwrite from the override file to avoid having to change
> the upstream configuration. Override files would never be part of a
> package as a rule, and thus could be fully owner by a user. Still, an
> external script or a configuration management system, would have to
> edit this file to start or stop a service. This is less than ideal,
> but solves the concerns about conflicting with packaging. Besides,
> this file should be nonexistent in the majority of cases.
>
> In my scenarios, having the existence of /etc/init/apache.manual
> trigger upstart to not automatically start or stop the service, but
> allow it to be manually started by the user, would be preferred. I
> recognize upstart is driven by the characteristics of desktop services
> and this could come off as configuration file cruft in those use
> cases. This would be preferable for developers to invoke a permanent
> programmatic change from a script.
>
> --
> 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.
>
>
>

Another usercase. I want sometimes to enable Samba to share files with someone, however, I don't want to have samba running all the time.

According to this http://ubuntuforums.org/showthread.php?t=1468111&page=2

Red Hat and Mandriva use "service daemon off".

Upstart in Natty now supports Override files and the manual stanza. See:

  https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview#Upstart

Rolling back to In Progress since this hasn't actually landed in trunk yet

Would I be likely to garner any traction in nominating this for SRU, considering the impact for server and cluster environments (and the fact that core services like MySQL are on upstart), the majority of which will be using LTS? Or at the very minimum, a backport? Judging from the attitude towards this bug in the comments here, I'm not confident, but any sysadmin will testify to the importance (necessity) of this feature.

"Would I be likely to garner any traction in nominating this for SRU, considering the impact for server and cluster environments (and the fact that core services like MySQL are on upstart)"

Seconded. This is a critical feature, imo...

Please don't change upstream tasks to Fix Committed unless the code is in trunk (lp:upstart) or Fix Released unless the code is in a released tarball.

To track changes to Upstart in Natty, add an Ubuntu "Task" to the bug.

Nominating for SRU:

The moving of core system daemons (ie - mysql, libvirt-bin, etc) to Upstart without the means for non-destructive disabling impairs the ability to use those services on servers, particularly in clustered environments. This is a regression.

The addition of the 'manual' stanza, and .override files in upstart-0.9.4-1ubuntu1 resolves this problem.

A minimal patch will need to be extracted from the other changes introduced in 0.9.4-1ubuntu1, will extract upon approval from SRU team.

TEST CASE: Attempt to disable service managed by upstart, whilst maintaining the ability to actually start the service manually. This is impossible. As a sample use case, without the ability to move clustered services under cluster control, concurrent service starting will destroy shared data on non-cluster-aware filesystems.

The patch would add additional functionality with minimal impact, there should be no regression for existing users.

Please let me know if I'm required to extract the patch and produce the candidate package.

Assuming I don't have permission to set the appropriate flags here - can't see the options described in the SRU document.

pdf: in order to set SRU flags, I think you have to look at the bug from the
Ubuntu POV ... check that the URL is of the form /ubuntu/source/+upstart/..

Excerpts from pdf's message of Mon Apr 04 12:56:26 UTC 2011:
> Nominating for SRU:
>
> The moving of core system daemons (ie - mysql, libvirt-bin, etc) to
> Upstart without the means for non-destructive disabling impairs the
> ability to use those services on servers, particularly in clustered
> environments. This is a regression.
>
> The addition of the 'manual' stanza, and .override files in
> upstart-0.9.4-1ubuntu1 resolves this problem.
>
> A minimal patch will need to be extracted from the other changes
> introduced in 0.9.4-1ubuntu1, will extract upon approval from SRU team.
>
> TEST CASE: Attempt to disable service managed by upstart, whilst
> maintaining the ability to actually start the service manually. This is
> impossible. As a sample use case, without the ability to move clustered
> services under cluster control, concurrent service starting will destroy
> shared data on non-cluster-aware filesystems.
>
> The patch would add additional functionality with minimal impact, there
> should be no regression for existing users.

I'm not totally against this for SRU, but I would like to make sure we are
sure that it is entirely necessary before going forward.

First, I would like to refute the statement that it is "impossible".

This can be achieved on a script-specific level with just sed:

sed -i.bak -e 's/^start on/#start on/;s/^\s*and/# and/;' /etc/init/mysql.conf

This is not destructive, the original file is preserved, though it is
definitely a hack to get around the missing functionality in version
0.6.5 of upstart.

It is not 100% reliable, as users may have customized the start on
conditions, but that can also be detected and dealt with. Furthermore, the
format of the upstart job is stable enough that one could write a script
to parse the full start on and disable the lines that way.

Meanwhile, cherry picking features like this into such a critical piece
of system infrastructure like init should not be done lightly.

>
>
> Please let me know if I'm required to extract the patch and produce the candidate package.
>

I've added tasks for Maverick and Lucid. This does not mean it will be
accepted, but provides a means to specify what the state in those releases
is. In all liklihood we may decide not to fix it in lucid and/or maverick

On 05/04/11 05:04, Clint Byrum wrote:
> I'm not totally against this for SRU, but I would like to make sure we are
> sure that it is entirely necessary before going forward.

Understood.

> First, I would like to refute the statement that it is "impossible".
>
> This can be achieved on a script-specific level with just sed:
>
> sed -i.bak -e 's/^start on/#start on/;s/^\s*and/# and/;'
> /etc/init/mysql.conf
>
> This is not destructive, the original file is preserved, though it is
> definitely a hack to get around the missing functionality in version
> 0.6.5 of upstart.

This does provide an avenue to allowing the disabling of jobs, and this
is essentially how we've been hacking around this, my concern is that a
single missed merge at package upgrade would result in data corruption
in our clustered environments (I work for an ISV and ship numerous
systems to clients based on Ubuntu Server). The migration to Lucid for
these clusters has been particularly painful do to the introduction of
Upstart, since we need to modify the jobs of every cluster-controlled
service under Upstart, and maintain vigilance during upgrades.

> It is not 100% reliable, as users may have customized the start on
> conditions, but that can also be detected and dealt with. Furthermore, the
> format of the upstart job is stable enough that one could write a script
> to parse the full start on and disable the lines that way.

A generic parser might be an option, though if this doesn't make it
through SRU, I think my solution will have to be to port this feature
and maintain the package in our private override repo, though I'd prefer
not to be maintaining a core infrastructure package that way. The
script hacking is just too brittle to be a long-term solution for us.

> Meanwhile, cherry picking features like this into such a critical piece
> of system infrastructure like init should not be done lightly.

I certainly understand this, however I do see the lack of standard job
control for core services as a serious regression.

What is the wrap up of the fix now?

Excerpts from Andy Hauser's message of Fri Jun 17 08:31:38 UTC 2011:
> What is the wrap up of the fix now?

You can stop "job" from automatically starting with

sudo sh -c 'echo manual >> /etc/init/job.override'

>
> --
> You received this bug notification because you are subscribed to upstart
> .
> https://bugs.launchpad.net/bugs/94065
>
> Title:
> init: add non-destructive means to disable a job
>
> Status in Upstart:
> Fix Released
> Status in “upstart” package in Ubuntu:
> Fix Released
> Status in “upstart” source package in Lucid:
> New
> Status in “upstart” source package in Maverick:
> New
>
> 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.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/upstart/+bug/94065/+subscriptions