upstart

Bug #94065
Comment #45

Comment 45 for bug 94065

Revision history for this message

pdf (pdffs) wrote on 2011-04-05: Re: [Bug 94065] Re: init: add non-destructive means to disable a job

#45

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.

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.

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.