Tag Archives: cups

Puppet service resource provider

Well, first of all I think the title of this post won’t entirely reflect its content. However, I need to go ahead and post this now.

At work, We’ve been having issues with cups service not running on some Kubuntu 14.04 desktops. This should not happen since even if cups service is dead, we have Puppet agent running on each machine
to check and make sure that ‘cups’ is running else will be automatically restarted.

Here’s the snippet of cups::service manifest:

#-
class cups::service {
  
  service { 'cups':
    ensure     => running,
    enable     => true,
    hasstatus  => true,
    hasrestart => true,
  }

}

I still don’t know what cause cups to die or terminated. However, when that happens, I manually check
cups service by running:

# service cups status
cups start/running,

According to the output, it looks like cups is still running. But if instead I run:

# /etc/init.d/cups status
 * cupsd is not running

To fix this cups issue, cups service needs to be started:

# /etc/init.d/cups start
# /etc/init.d/cups status
 * cups is running

It seems the upstart service used on Kubuntu to check status for cups is broken. Surprisingly, I haven’t found
any bugs report about this yet. Maybe this problem is unique to my environment; or maybe I should file a bug myself!

Anyway, a work around is force Puppet to start cups service with init.d instead of using upstart. In Puppet, we can do this by setting the provider attribute of service resource.

#-
class cups::service {
  
  service { 'cups':
    ensure     => running,
    enable     => true,
    hasstatus  => true,
    hasrestart => true,
    provider   => init,
  }

}

The above Puppet code works fine with Puppet agent 3.8.4. The bad news is, this doesn’t work with Puppet agent 4.3.0.

Here’s how I found out that provider => init doesn’t work with Puppet agent 4.3.0:

# /opt/puppetlabs/puppet/bin/puppet resource service cups provider=init --debug
Debug: Runtime environment: puppet_version=4.3.0, ruby_version=2.1.7, run_mode=user, default_encoding=UTF-8
Debug: Evicting cache entry for environment 'production'
...
Debug: Puppet::Type::Service::ProviderInit: false value when expecting true
Error: /Service[cups]: Provider init is not functional on this host
Debug: Finishing transaction 40939920
Debug: Storing state
Debug: Stored state in 0.05 seconds
Debug: Puppet::Type::Service::ProviderInit: false value when expecting true
Error: Could not run: Provider init is not functional on this host

Fortunately, I found a common provider which works on both older and new version of Puppet agent. It’s called ‘debian’!

# /opt/puppetlabs/puppet/bin/puppet resource service cups provider=debian --debug
...
Debug: Executing: '/etc/init.d/cups status'
Debug: Finishing transaction 17147680
Debug: Storing state
Debug: Stored state in 0.05 seconds
Debug: Executing: '/etc/init.d/cups status'
service { 'cups':
  ensure => 'running',
}

Here’s a revised cups service manifest:

class cups::service {
  # [2015-12-16:SS] There has been an issue with upstart service
  #                 starting cups. Sometimes it reports cups is running,
  #                 when it in fact is not.
  #                 In Puppet, we can explicitly tells services to use
  #                 different startup script. In this case, 'init.d'.
  service { 'cups':
    ensure     => running,
    enable     => true,
    hasstatus  => true,
    hasrestart => true,
    provider   => debian,
  }

}

Well, that’s it. If you have any comments or suggestions, do let me know.