Puppet users - Apr 2013 - problems ensuring that a service is absent

Hi,

I''m trying to be really, really sure that a specific service is not 
running. The central part of this looks like that:


   service { ''foo'': ensure => stopped, enable => false }
   ->
   package { ''foo'': ensure => purged }

The astute reader will notice that on the second run puppet will 
complain that the init script for foo is missing:
> Error: /Stage[main]//Service[foo]: Could not evaluate: Could not find init
script for ''foo''
Of course, I could either hope that removing the package will properly 
clean up or implement stopping the service in a exec resource, but 
both[1] do not appeal to my inner Monk[2].


Does anyone have a better idea?


Best Regards, David



[1]http://weblogs.asp.net/alex_papadimoulis/archive/2005/05/25/408925.aspx
[2]http://en.wikipedia.org/wiki/Monk_(TV_series)

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

On Thu, 25 Apr 2013 09:50:23 +0200
David Schmitt <david@dasz.at> wrote:
>    service { ''foo'': ensure => stopped, enable =>
false }
>    ->
>    package { ''foo'': ensure => purged }
> 
> The astute reader will notice that on the second run puppet will 
> complain that the init script for foo is missing:
> 
> > Error: /Stage[main]//Service[foo]: Could not evaluate: Could not
> > find init script for ''foo''
> 
> Of course, I could either hope that removing the package will
> properly clean up or implement stopping the service in a exec
> resource, but both[1] do not appeal to my inner Monk[2].
Well, I''m only most familiar with rpm-based distributions, but I can
assure you than any properly built package will make sure to stop and
disable any service it contained before it gets removed.

So typically you''re fine with just ensuring the package is absent, and
enclosing the service inside an "if $ensure ==
''present''" or similar.
If that''s not enough, it should be considered a packaging bug.

Matthias

-- 
            Matthias Saou                  ██          ██
                                             ██      ██
Web: http://matthias.saou.eu/              ██████████████
Mail/XMPP:  matthias@saou.eu             ████  ██████  ████
                                       ██████████████████████
GPG: 4096R/E755CC63                    ██  ██████████████  ██
     8D91 7E2E F048 9C9C 46AF          ██  ██          ██  ██
     21A9 7A51 7B82 E755 CC63                ████  ████

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

On Thursday, April 25, 2013 2:50:23 AM UTC-5, David Schmitt
wrote:
>
> Hi, 
>
> I''m trying to be really, really sure that a specific service is
not
> running. The central part of this looks like that: 
>
>
>    service { ''foo'': ensure => stopped, enable =>
false }
>    -> 
>    package { ''foo'': ensure => purged } 
>
> The astute reader will notice that on the second run puppet will 
> complain that the init script for foo is missing: 
>
> > Error: /Stage[main]//Service[foo]: Could not evaluate: Could not find 
> init script for ''foo'' 
>
> Of course, I could either hope that removing the package will properly 
> clean up or implement stopping the service in a exec resource, but 
> both[1] do not appeal to my inner Monk[2]. 
>
>
You cannot manage a resource that does not exist, at least not without 
creating it.  When you remove Package[''foo''],
Service[''foo''] ceases to
exist as such.  If you are concerned that removing the package may leave 
behind a running process, then you need to recognize that it''s the
*process*you want to manage.  Though such a process may be related to the
erstwhile
service, it is not the service itself.

Perhaps your inner Monk would be pacified if you wrap an Exec in a 
for-purpose defined type (or even a custom native type, though your Monk 
affinity would need to be strong for that).  I''m thinking something
along
these lines:

define site::forbidden_process() {
    exec { "/usr/bin/killall ${name}": }
}

You could go crazy with additional parameters and refinements, but
that''s
the core.

Another alternative is to create a custom fact that reports on whether the 
service initially exists, and then use it to conditionally manage the 
service stopped.  Do note that service existence is different from the 
package being installed.  It is possible to remove the service without 
removing its package (e.g. by manually removing its init script), and it is 
possible for a service to exist without a corresponding package (e.g. as a 
result of a local installation from source).


John

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

On 2013-04-25 16:29, jcbollinger wrote:
>
>
> On Thursday, April 25, 2013 2:50:23 AM UTC-5, David Schmitt wrote:
>
>     Hi,
>
>     I''m trying to be really, really sure that a specific service
is not
>     running. The central part of this looks like that:
>
>
>     service { ''foo'': ensure => stopped, enable =>
false }
>     ->
>     package { ''foo'': ensure => purged }
>
>     The astute reader will notice that on the second run puppet will
>     complain that the init script for foo is missing:
>
>      > Error: /Stage[main]//Service[foo]: Could not evaluate: Could not
>     find init script for ''foo''
>
>     Of course, I could either hope that removing the package will properly
>     clean up or implement stopping the service in a exec resource, but
>     both[1] do not appeal to my inner Monk[2].
>
>
> You cannot manage a resource that does not exist, at least not without
> creating it. When you remove Package[''foo''],
Service[''foo''] ceases to
> exist as such. If you are concerned that removing the package may leave
> behind a running process, then you need to recognize that it''s the
> /process/ you want to manage. Though such a process may be related to
> the erstwhile service, it is not the service itself.
>
> Perhaps your inner Monk would be pacified if you wrap an Exec in a
> for-purpose defined type (or even a custom native type, though your Monk
> affinity would need to be strong for that). I''m thinking something
along
> these lines:
>
> define site::forbidden_process() {
> exec { "/usr/bin/killall ${name}": }
> }
>
> You could go crazy with additional parameters and refinements, but
> that''s the core.
>
> Another alternative is to create a custom fact that reports on whether
> the service initially exists, and then use it to conditionally manage
> the service stopped. Do note that service existence is different from
> the package being installed. It is possible to remove the service
> without removing its package (e.g. by manually removing its init
> script), and it is possible for a service to exist without a
> corresponding package (e.g. as a result of a local installation from
> source).
Thanks for your excellent write-up. Together with Matthias'' assertion 
that even rpm-based distros nowadays clean up services when removing 
packages, you have convinced me that it is better to just leave it alone.

If specific versions of foo actually exhibit orphaned processes, they 
can be cleaned out by using an exec or a specifically crafted service 
resource.


Regards, David


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