Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5345

SysV init script managed by 'init' provider instead of 'debian' provider on Ubuntu1004,1204,1404

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Duplicate
    • Affects Version/s: PUP 4.2.2
    • Fix Version/s: None
    • Component/s: Types and Providers
    • Labels:
      None
    • Template:

      Description

      This is probably very similar to PUP-5016 but with a different set of defaults. On Ubuntu platforms defaulting to upstart, a sysv init script ends up using the init rather than the debian provider, and therefore will not show the enable parameter when using `puppet resource service`. (Unless the 'enable' parameter is specifically set, see below)

      For example, on Ubuntu1404, with puppet-agent 1.2.2 installed:

      root@pe-201520-agent:/home/vagrant# puppet resource service puppet
      service { 'puppet':
        ensure => 'running',
      }
      root@pe-201520-agent:/home/vagrant# puppet resource service puppet --param provider --param enable
      service { 'puppet':
        ensure   => 'running',
        provider => 'init',
      }
      

      root@pe-201520-agent:/home/vagrant# puppet resource service puppet --debug
      Debug: Runtime environment: puppet_version=4.2.1, ruby_version=2.1.6, run_mode=user, default_encoding=UTF-8
      ...
      Debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
      Debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
      Debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
      Debug: Puppet::Type::Service::ProviderOpenbsd: file /usr/sbin/rcctl does not exist
      Debug: Puppet::Type::Service::ProviderRedhat: file /sbin/chkconfig does not exist
      Debug: Puppet::Type::Service::ProviderOpenrc: file /bin/rc-status does not exist
      Debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
      Debug: Puppet::Type::Service::ProviderSystemd: file systemctl does not exist
      Debug: Facter: searching for custom fact "operatingsystemmajrelease".
      Debug: Facter: searching for operatingsystemmajrelease.rb in /opt/puppetlabs/puppet/cache/lib/facter.
      Debug: Facter: searching for operatingsystemmajrelease.rb in /opt/puppetlabs/puppet/cache/lib/facter.
      Debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
      Debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
      Debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
      Debug: Puppet::Type::Service::ProviderOpenbsd: file /usr/sbin/rcctl does not exist
      Debug: Puppet::Type::Service::ProviderRedhat: file /sbin/chkconfig does not exist
      Debug: Puppet::Type::Service::ProviderOpenrc: file /bin/rc-status does not exist
      Debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
      Debug: Puppet::Type::Service::ProviderSystemd: file systemctl does not exist
      Debug: Executing '/sbin/initctl list'
      Debug: /Service[mountnfs-bootclean.sh]: Provider upstart does not support features flaggable; not managing attribute flags
      ...
      Debug: /Service[mcollective]: Provider init does not support features enableable; not managing attribute enable
      Debug: /Service[mcollective]: Provider init does not support features flaggable; not managing attribute flags
      ...
      Debug: /Service[puppet]: Provider init does not support features enableable; not managing attribute enable
      Debug: /Service[puppet]: Provider init does not support features flaggable; not managing attribute flags
      ...
      Debug: Service mcollective found in both init and debian; skipping the debian version
      ...
      Debug: Service puppet found in both init and debian; skipping the debian version
      ...
      Debug: Executing: '/etc/init.d/puppet status'
      service { 'puppet':
        ensure => 'running',
      }
      

      Note that enableing and disabling the services does work though:

      root@pe-201520-agent:/home/vagrant# puppet resource service puppet enable=false --param provider
      Notice: /Service[puppet]/enable: enable changed 'true' to 'false'
      service { 'puppet':
        ensure   => 'running',
        enable   => 'false',
        provider => 'upstart',
      }
      root@pe-201520-agent:/home/vagrant# puppet resource service puppet enable=true --param provider
      Notice: /Service[puppet]/enable: enable changed 'false' to 'true'
      service { 'puppet':
        ensure   => 'running',
        enable   => 'true',
        provider => 'upstart',
      }
      

      It looks like the upstart provider is preferred in that case which falls back to debian provider as needed when dealing with a non-upstart script.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              kylo Kylo Ginsberg
              Reporter:
              joshua.partlow Joshua Partlow
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support