Docker Debian 7.4 image but seems to be there for any fresh Debian 7.4 installation.

Merged to master in https://github.com/puppetlabs/puppet/commit/6e6282f1784d315ade33a7077d62a9968abb1403. This will be release in puppet 4.0.0.

Kurt Wall in case you can get to this before me

i'll just leave this here: https://github.com/petems/puppetlabs-inifile/tree/wercker_setup

Eric Thompson or Kurt Wall have you looked in to reproduction steps on this one?

John Duarte I got sniped by puppet preview work the last few days. I'll get back to this Friday.

@Kylo When you have a moment, can we talk about validating this? I've got a Docker container running Debian. My initial thought is to install puppet, create a module that needs the insserv service, and see if it works. Or maybe even just say puppet apply -e 'service { "insserv": ensure=>running,}'?

Arthur Leonard Andersen Can you supply a complete reproduction case, please? I'd like to validate this fix but want to do so against the case you encountered. Thanks!

After an email/hipchat discussion, Kylo and I decided to validate that the service provider hasn't regressed. It hasn't.

# puppet apply -e "service { 'cron': ensure => stopped }"

Notice: Compiled catalog for kqascu72o57zqcp.delivery.puppetlabs.net in environment production in 0.07 seconds

Notice: /Stage[main]/Main/Service[cron]/ensure: ensure changed 'running' to 'stopped'

Notice: Finished catalog run in 0.24 seconds

root@kqascu72o57zqcp:~# ps -ef | grep cron

root     18903 11948  0 11:16 pts/0    00:00:00 grep cron

# puppet apply -e "service { 'cron': ensure => running }"

Notice: Compiled catalog for kqascu72o57zqcp.delivery.puppetlabs.net in environment production in 0.07 seconds

Notice: /Stage[main]/Main/Service[cron]/ensure: ensure changed 'stopped' to 'running'

Notice: Finished catalog run in 0.06 seconds

# ps -ef | grep cron

root     19117     1  0 11:16 ?        00:00:00 /usr/sbin/cron

root     19119 11948  0 11:16 pts/0    00:00:00 grep cron

# puppet resource service cron

service { 'cron':

  ensure => 'running',

  enable => 'true',

}

cool. normally i'd say that if this were a regression candidate that we should write an acceptance test for this, but since we don't have docker infra, maybe not.

Reopening this ticket to target the fix into the 3.8 branch. This has already been fixed for 4.x, so additional functional review will be limited to the 3.x branch.

You can also easily reproduce it if you use https://github.com/devopsconsulting/puppet-disablestart on your system which just places a /usr/sbin/policy-rc.d file which exits with 101.
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/debian.rb#L35 can then be used to check if the service is falsely disabled or not.

Assigning to myself, but leaving closed, to investigate the repro case suggested by Stefan Andres. Thanks Stefan!

Crud. I mis-jira'd last night. I didn't mean to close but to move to Ready for Test, so fixing that now. Thanks for picking this up Kurt Wall