Puppet users - Aug 2011 - Re: Re: Service resource does not turn services off on reboots

Hi,

Thanks for the help.

I do see these services coming back up if I reboot the system. They are
brought down again when puppet run for the first time. Besides, I have never
seen Puppet calling chkconfig service off even in the first run, when the
services were in a up state after the system installation. I wonder if I
missed something.

Any other idea?

thanks,
-fred




On Mon, Aug 29, 2011 at 7:27 AM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Aug 26, 1:26 pm, Frederiko Costa <freder...@gmail.com> wrote:
> > Hi folks,
> >
> > The question I have is regarding to Service resource on Red Hat
systems.
> I
> > have the following example:
> >
> > service { [ "anacron", "atd" ]:
> >        ensure => stopped,
> >         enable => false,
> >         hasrestart => true,
> >         hasstatus => true,
> >   }
> >
> > It runs fine, disabling the service while the system is up. Debugging
it,
> I
> > noticed that it run the following:
> > debug: Service[atd](provider=redhat): Executing
''/sbin/service atd
> status''
> > debug: Puppet::Type::Service::
> > ProviderRedhat: Executing ''/sbin/chkconfig atd''
> >
> > The idea is to disable it completely, so it does not come back in the
> next
> > reboot. By running ''/sbin/chkconfig atd'', that does
not happen. So, the
> > correct command, I think, would be ''/sbin/chkconfig atd
off''.
> >
> > Is there any way to accomplish this?
>
>
> Are you sure it''s broken?  I strongly suspect that the Puppet
agent
> runs "/sbin/chkconfig atd" as part of determining the current
state of
> Service[''atd''], not in an attempt to modify that state. 
In
> particular, it is determining whether the service is currently
> enabled.  If the resource is already in the desired state then Puppet
> will not modify it (so you will not see ''/sbin/chkconfig atd
off'' in
> that case).
>
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Something you are doing is causing your messages to not be threaded
together with each other or with others'' messages -- instead, each one
is starting a new thread.  That makes it extremely difficult to track
the discussion, so I hope you can figure out what you''re doing and fix
it.  One alternative would be to post via Google Groups''s web
interface.

On Aug 29, 10:24 am, Frederiko Costa <freder...@gmail.com>
wrote:
> Hi,
>
> Thanks for the help.
>
> I do see these services coming back up if I reboot the system. They are
> brought down again when puppet run for the first time. Besides, I have
never
> seen Puppet calling chkconfig service off even in the first run, when the
> services were in a up state after the system installation. I wonder if I
> missed something.

Likely you have missed something, for the Service resource works as
advertised on Redhat-family systems for many other people.  Things to
check:

1) Make sure the Puppet agent is successfully retrieving its catalog
from the master.  If it cannot (e.g. if catalog compilation fails on
the master) then the agent will apply the last catalog it did manage
to retrieve, which may not have the expected properties declared for
the resources in question.

2) Make sure the catalog that is applied in fact does declare the
resource properties you expect it to do.  You can do this by looking
at the catalog YAML in the agent''s cache.

3) Run chkconfig immediately after a run of the Puppet agent to check
whether the services in question are enabled, and in which runlevels.
This is your guage of whether Puppet did the right thing with respect
to Service''s ''enable'' property.  For best results,
test with a minimal
catalog so that the Puppet run doesn''t drag out.

4) Disable Puppet, restart, and immediately run chkconfig after the
system comes up.  Are the services in question still configured as
Puppet left them?  If not, then you have something else competing with
Puppet for control of those resources.  If so, but the services were
started anyway, then something very strange and out-of-spec is going
on.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.