puppet incorrectly enumerates upstart jobs when called with "puppet resource service"

[Felix Krull]

As the summary says: trying to run 'status startpar-bridge' fails with the output 'status: Unknown parameter: JOB' and exit code 1. This is a problem when using puppet as running 'puppet resource service' will fail because of this error. This is on a very fresh, up-to-date Ubuntu 13.10 (Kubuntu, technically).

[Steve Langasek (vorlon)]

This is a bug in puppet, then; there's no reason that puppet should be trying to call 'status startpar-bridge', and the fact that it's doing so is a bug in the puppet code in question.

[Stig Sandbeck Mathisen (ssm)]

Steve Langasek <email address hidden> writes:

> This is a bug in puppet, then; there's no reason that puppet should be
> trying to call 'status startpar-bridge', and the fact that it's doing
> so is a bug in the puppet code in question.

When you run "puppet resource service", puppet will enumerate _all_
services on that server (init scripts, upstart jobs, systemd services,
whatnot, and then check if it is running, and if it is enabled on boot.

When the operatingsystem is "ubuntu", the service provider is "upstart",
The relevant code for handling services on ubuntu is:

  defaultfor :operatingsystem => :ubuntu

  commands :start => "/sbin/start",
           :stop => "/sbin/stop",
           :restart => "/sbin/restart",
           :status_exec => "/sbin/status",
           :initctl => "/sbin/initctl"

Is this wrong for Ubuntu?

--
Stig Sandbeck Mathisen

[Steve Langasek (vorlon)]

Hi Stig,

On Sat, Mar 15, 2014 at 08:19:04PM +0100, Stig Sandbeck Mathisen wrote:
> Steve Langasek <email address hidden> writes:

> > This is a bug in puppet, then; there's no reason that puppet should be
> > trying to call 'status startpar-bridge', and the fact that it's doing
> > so is a bug in the puppet code in question.

> When you run "puppet resource service", puppet will enumerate _all_
> services on that server (init scripts, upstart jobs, systemd services,
> whatnot, and then check if it is running, and if it is enabled on boot.

> When the operatingsystem is "ubuntu", the service provider is "upstart",
> The relevant code for handling services on ubuntu is:

> defaultfor :operatingsystem => :ubuntu

> commands :start => "/sbin/start",
> :stop => "/sbin/stop",
> :restart => "/sbin/restart",
> :status_exec => "/sbin/status",
> :initctl => "/sbin/initctl"

> Is this wrong for Ubuntu?

Not being particularly familiar with puppet's internals, I don't know if the
above is wrong per se. But startpar-bridge (and other jobs present on
Ubuntu by default, such as network-interface and network-interface-security)
are instantiated jobs; calling 'status network-interface' without specifying
a network interface is not meaningful, and any errors returned from 'status'
about 'unknown parameter' or 'unknown instance' should not be treated as
failures by puppet.

If puppet needs to get a list of all jobs running on the system, including
instantiated jobs, it should use the 'initctl list' interface.

[Stig Sandbeck Mathisen (ssm)]

Steve Langasek <email address hidden> writes:

> Not being particularly familiar with puppet's internals, I don't know
> if the above is wrong per se. But startpar-bridge (and other jobs
> present on Ubuntu by default, such as network-interface and
> network-interface-security) are instantiated jobs; calling 'status
> network-interface' without specifying a network interface is not
> meaningful, and any errors returned from 'status' about 'unknown
> parameter' or 'unknown instance' should not be treated as failures by
> puppet.

That was what I was missing; instantiation. Thanks. :)

> If puppet needs to get a list of all jobs running on the system,
> including instantiated jobs, it should use the 'initctl list'
> interface.

It does, but I think something is off inside puppet's guts.

As far as I can see in the source (ruby code at
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/upstart.rb#L47)
it does "initctl list", and picks the first word of each line, unless
the service in question is "network-interface" or
"network-interface-security".

It looks like puppet does not handle instances in a generic way, but
special cases it for "network-interface" and
"network-interface-security", and then hardcoded with INTERFACE=foo and
JOB=bar.

It looks like the instance variable name differs between services, so if
my assumption is correct, I wonder what would be the "generic" way of
enumerating services the correct way would be to find this variable for
all instanciated services.

--
Stig Sandbeck Mathisen

[Matthew Wedgwood (mew)]

Fixed in upstream:
https://tickets.puppetlabs.com/browse/PUP-1332

[Stig Sandbeck Mathisen (ssm)]

On Wed, Apr 30, 2014 at 05:02:44PM -0000, Matthew Wedgwood wrote:
> Fixed in upstream:
> https://tickets.puppetlabs.com/browse/PUP-1332

Not sure about the "fixed". They are adding to a list of services which are
known to need parameters to start. They are not fixing the upstart service
provider.