restarting "service" when configuration changes
Sans
word" to use here but it's not working here; my case is a bit
different. This is what I have:
***************************************************************
define line_check($fname, $line, $bool = 'false') {
exec { "/bin/echo '${line}' >> '${fname}'":
unless => "/bin/grep -q '^$line' '$fname'",
refreshonly => "$bool";
}
}
class zmfs::config {
zmfs::defined::line_check {'auto.master':
fname => '/etc/auto.master',
line => '/zmfs /etc/auto.zmfs',
notify => Class['zmfs::service'];
}
}
class zmfs::service {
service { 'autofs':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
status => 'service zmfs probe',
require => Package['zmfs','zmfs-init-scripts'];
}
}
***************************************************************
So, I'm expecting, whenever "/etc/auto.master" is modified, autofs
service will be restarted but that's not case I see here. What am I
missing?
Another question: Can I just do "service { 'autofs':" or "service
{ 'nfs':" (or any given standard unix/linux service) just like that?
I'm wondering if that part is being completely ignored.
Cheers,
San
Bekir Dogan
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Jo Rhett
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:
> Try
> notify => Service['autofs']
Right. As far as I know, classes do not forward signals to resources
they contain.
Furthermore, you should consider whether it would be appropriate to
combine your two classes. That a resource belonging to one wants to
signal a resource belonging to the other is a hint in that direction
(but no more than that). I'm not seeing what you gain by defining
such fine-grained classes, especially with the implicit dependencies
among them (see next).
Also, if you do not combine classes, then be sure each class
'include's the other classes whose resources it references. For
instance, class zmfs::service should contain "include 'zmfs::config'"
at the beginning of its body. Class zmfs::service should 'include'
whatever class(es) declares the the 'zmfs' and 'zmfs-init-scripts'
packages. On the practical side, this protects you from catalog
compilation failures arising from varying parse order. On the
conceptual side, it's the Right Thing for classes to formally declare
their dependencies.
John
jcbollinger
On Dec 14, 7:35 am, Sans <r.santanu....@gmail.com> wrote:
> Another question: Can I just do "service { 'autofs':" or "service
> { 'nfs':" (or any given standard unix/linux service) just like that?
As opposed to what? The service name to use is whatever the system's
tools use to refer to the service. For example, if your system
provides the 'chkconfig' and 'service' commands for managing services,
then your Puppet manifests should name Service resources with the
names that you would use with those tools.
> I'm wondering if that part is being completely ignored.
Unlikely.
John
Felix Frank
> Right. As far as I know, classes do not forward signals to resources
> they contain.
Which really is a major pitfall. Any insight on why it's not done?
Cheers,
Felix
Sans
On Dec 15, 2:08 pm, jcbollinger <John.Bollin...@stJude.org> wrote:
> On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:
>
> > Try
> > notify => Service['autofs']
>
> Right. As far as I know, classes do not forward signals to resources
> they contain.
>
Are you absolutely sure about that? My understanding was to use
something like Class['zmfs::service'] only to avoid running individual
services separately in that class.
> Furthermore, you should consider whether it would be appropriate to
> combine your two classes. That a resource belonging to one wants to
> signal a resource belonging to the other is a hint in that direction
> (but no more than that). I'm not seeing what you gain by defining
> such fine-grained classes, especially with the implicit dependencies
> among them (see next).
>
Those three code snippets are in three different files, namely
definition.pp, config.pp and service.pp respectively. And there is a
"config.pp" where
The "line_check" definition gets reused for various files in the
module. [re]Starting zmfs is not just enough, it's needs some other
services to be restarted, "autofs" being one of the most important
ones. So, what I want is to restart "autofs" as soon as the "/zmfs /
etc/auto.zmfs" is added to the auto.master file, say for example for
the very first time. "zmfs" itself still just works without restarting
(even starting) the "autofs" but it won't be completely usable. So, in
fact, this is the actual service.pp file:
*******************************************
class zmfs::service {
service {
'zmfs':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
#status => '/etc/zmfs/service_zmfs',
require => Package['zmfs','zmfs-init-scripts'];
'autofs':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
status => 'service zmfs probe',
require => Package['zmfs','zmfs-init-scripts'];
}
}
*******************************************
I wrote (at least trying to) this module to use by the several other
sys-admins, where either "autofs" is already running and in some cases
the "auto.master" itself is being maintained by another puppet module.
So, I had to make sure my module must restart autofs after adding the
appropriate line to the file. but that's not happening.
On the other hand, if I take the 'service autofs' out of the equation
and use an external script (service_zmfs) with "status"
****************************************
#!/usr/bin/perl
# file: service_zmfs
use strict;
use warnings;
my @checks = (
"serviceautofs restart",
"service zmfs probe",
);
for my $check ( @checks ) {
$check .= " 2>&1 > /dev/null"; # suppress output
system( $check ) == 0 or exit 1;
}
*************************************
it works. Still don't fully get it.
Cheers!!
jcbollinger
On Dec 15, 8:33 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
I suspect some historical inertia, but it's also not clear to me that
the historical behavior is less desirable. It might be reasonable if
the effect of refreshing a class were to refresh all of its resources,
but I don't see that as the singular right thing to do. Furthermore,
I suspect that making class refreshes work that way is a far more
complicated proposal than it might at first appear.
John
jcbollinger
On Dec 15, 10:16 am, Sans <r.santanu....@gmail.com> wrote:
> On Dec 15, 2:08 pm, jcbollinger <John.Bollin...@stJude.org> wrote:
>
> > On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:
>
> > > Try
> > > notify => Service['autofs']
>
> > Right. As far as I know, classes do not forward signals to resources
> > they contain.
>
> Are you absolutely sure about that?
"As far as I know" was meant to convey that no, I am not absolutely
sure.
> My understanding was to use
> something like Class['zmfs::service'] only to avoid running individual
> services separately in that class.
That's understandable, but evidently it doesn't work with resource
signaling. Moreover, it's not obvious to me that that's what you
really want anyway. For instance, do you care in what order the
resources in class zmfs::service get refreshed? If so, then signaling
via the class would not be correct anyway.
> > Furthermore, you should consider whether it would be appropriate to
> > combine your two classes. That a resource belonging to one wants to
> > signal a resource belonging to the other is a hint in that direction
> > (but no more than that). I'm not seeing what you gain by defining
> > such fine-grained classes, especially with the implicit dependencies
> > among them (see next).
>
> Those three code snippets are in three different files, namely
> definition.pp, config.pp and service.pp respectively.
That's entirely beside the point, which is that resources that are
closely related to each other typically belong in the same class.
Consider: would any node ever want to include class zmfs::config but
not class zmfs::service? Would it be correct for a node to include
zmfs::service but not zmfs::config? If the anwer is no to both
questions, then why are these separate classes?
Note that as your manifests now stand, any node that includes
zmfs::config *must* also include zmfs::service, else its catalog will
not compile.
> And there is a
> "config.pp" where
>
> The "line_check" definition gets reused for various files in the
> module.
Very good, no problem with that.
> [re]Starting zmfs is not just enough, it's needs some other
> services to be restarted, "autofs" being one of the most important
> ones. So, what I want is to restart "autofs" as soon as the "/zmfs /
> etc/auto.zmfs" is added to the auto.master file, say for example for
> the very first time. "zmfs" itself still just works without restarting
> (even starting) the "autofs" but it won't be completely usable.
So what you're saying is that "notify => Service['autofs']" is
*exactly* what you want. You don't need to signal the other resources
in class zmfs::service; you only need to signal Service['autofs'].
> So, in
> fact, this is the actual service.pp file:
>
> *******************************************
> class zmfs::service {
> service {
> 'zmfs':
> enable => true,
> ensure => running,
> hasstatus => true,
> hasrestart => true,
> #status => '/etc/zmfs/service_zmfs',
> require => Package['zmfs','zmfs-init-scripts'];
>
> 'autofs':
> enable => true,
> ensure => running,
> hasstatus => true,
> hasrestart => true,
> status => 'service zmfs probe',
> require => Package['zmfs','zmfs-init-scripts'];
> }}
>
> *******************************************
>
> I wrote (at least trying to) this module to use by the several other
> sys-admins, where either "autofs" is already running and in some cases
> the "auto.master" itself is being maintained by another puppet module.
So in that case, putting Service['autofs'] in class zmfs::service is
probably harmful, unless you can be certain that every node that wants
to use autofs also wants to use zmfs, now and forever. Indeed, it is
quite strange that you contemplate managing the autofs service and one
of its configuration files in completely separate modules.
> So, I had to make sure my module must restart autofs after adding the
> appropriate line to the file. but that's not happening.
We understand what you are trying to accomplish, and it's quite
reasonable. Jo suggested a way for you to reach your objective --
notifying the Service instead of the class declaring it -- and the
more you explain, the more that suggestion seems exactly the right
thing to do.
> On the other hand, if I take the 'service autofs' out of the equation
> and use an external script (service_zmfs) with "status"
>
> ****************************************
> #!/usr/bin/perl
> # file: service_zmfs
>
> use strict;
> use warnings;
>
> my @checks = (
> "serviceautofs restart",
> "service zmfs probe",
> );
>
> for my $check ( @checks ) {
> $check .= " 2>&1 > /dev/null"; # suppress output
> system( $check ) == 0 or exit 1;}
>
> *************************************
>
> it works. Still don't fully get it.
What does one have to do with the other? If you prefer to use an
external script then fine, but that has nothing to do with how you
must write your Puppet manifests to achieve a similar result via
Service resources.
John
Nigel Kersten
"As far as I know" was meant to convey that no, I am not absolutely
On Dec 15, 10:16 am, Sans <r.santanu....@gmail.com> wrote:
> On Dec 15, 2:08 pm, jcbollinger <John.Bollin...@stJude.org> wrote:
>
> > On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:
>
> > > Try
> > > notify => Service['autofs']
>
> > Right. As far as I know, classes do not forward signals to resources
> > they contain.
>
> Are you absolutely sure about that?
sure.
jcbollinger
On Dec 15, 8:13 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:
> You can notify a class, and it forwards the signal to resources it contains.- Hide quoted text -
I stand corrected.
So, Nigel, do you have any idea why the OP's manifest is not doing
what he expects?
John
Nigel Kersten
Nigel Kersten
Product Manager, Puppet Labs