Puppet saying "changed 'stopped' to 'running'" while the service is running

[Eddie Mashayev]

Hi All,

I have some wired problem with my module to manage MacAfee services.
My lab have around 150 servers and 145 of them works fine with the module I’ve created.
There are 5 which shows these changes all the time although the service is in running state already.

[root@pingapp ~]# service cma status
cma (pid 1497) is running...
[root@pingapp ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Loading facts
Info: Caching catalog for il-pingapp-lp1.imperva.local
Info: Applying configuration version '1444807950'
Notice: /Stage[main]/Mcafee/Service[cma]/ensure: ensure changed 'stopped' to 'running'
Info: /Stage[main]/Mcafee/Service[cma]: Unscheduling refresh on Service[cma]
Notice: Finished catalog run in 1.80 seconds

My module is very simple:

class mcafee {
    if $check_nails_exsist  == 'true' {

      service { 'nails':
        ensure => "stopped",
        enable => false,
        hasstatus  => false,
        hasrestart => false,
      }
    }
    else {
      service { 'nails':
        ensure => "running",
        enable => true,
        hasstatus  => false,
        hasrestart => true,
        }
      service { 'cma':
        ensure => "running",
        enable => true,
        hasstatus  => false,
        hasrestart => true,
      }
    }
}

As I said in 145 servers with this module works fine according to the if statement and another 5 servers shows the "changed 'stopped' to 'running'"
I checked this thread https://projects.puppetlabs.com/issues/9798 but it didn’t help me.

Any suggestions for this weird behavior?

Thanks,

EddieM

[jcbollinger]

Your Service resources look wrong.  In the event that your services have no status command, you must not only set the `hasstatus` parameter to `false`, but also specify a status-check command manually via the `status` parameter.  Having done one but not the other, you leave Puppet with no way to determine whether the service is already running.  I'm not sure how Puppet will handle that, but ultimately, it's a flaw in your manifest.

I guess the agents you are managing are running Windows.  Are they running the same version of the Puppet agent?  It may be that different versions handle the flaws in your manifest differently.

Also, the default Service provider for Windows *does* claim to provide a 'status' command for all services, but on the other hand does not claim to provide a 'restart' command.  Your Service declarations specify differently on both points, for reasons that are unclear to me.  I talked about status already.  I suspect the restart issue is being cleaned up for you internally by the provider; perhaps that's what the unusual message "Unscheduling refresh on Service[cma]" is about.

I'm inclined to say that you should remove the declared `hasstatus' and 'hasrestart' properties from all the Service declarations, as I see no reason why it would be appropriate to override their default values in your case.  If you nevertheless continue to set 'hasstatus' to 'false', however, then you must provide a command via the 'status' parameter that Puppet will use to determine whether the service is already running.  See the docs for more details.


John

[Eddie Mashayev]

Hi,

Thanks for the response.
I removed the `hasstatus' and 'hasrestart' from my module and still the same result.
By the way, my agents are only CentOS 5/6/7.

Thanks,

EddieM

[jcbollinger]

On Wednesday, October 14, 2015 at 11:23:10 AM UTC-5, Eddie Mashayev wrote:

Hi,

Thanks for the response.
I removed the `hasstatus' and 'hasrestart' from my module and still the same result.
By the way, my agents are only CentOS 5/6/7.

 
Ah.  The "Mcafee" fooled me: I was not aware that they made any Linux products, and even a quick scan of their web site did not yield that nugget.

For the most part, however, that does not change my previous comments.  In particular, if you set a Service's 'hasstatus' parameter to 'false' then you need to specify a custom status command via the 'status' parameter.

On CentOS, `Service` resources will, by default, use the host's 'chkcfg' and 'service' commands to manage services.  They will check services' status via the exit code of '/sbin/service <service-name> status', which is interpreted according to the LSB specifications.  They will try to start, stop, or restart services analogously (e.g. '/sbin/service <service-name> start').  You should be able to see the exact commands the agent issues by running it with '--debug' output enabled.

Evidently, you do have initscripts for the "cma" and "nails" services (else I would expect Puppet to complain), but it may be that their behavior does not comply with LSB.  You can test that by exercising them manually via the 'service' command.  In that case, your options are to fix the initscript(s), or to specify custom 'status' commands, and possibly other custom service-management commands.


John