I have a class irqbalance with a service defined and it does not work as
expected and thats why I am asking for advice.
service { ''irqbalance'':
ensure => running,
enable => true,
require => Package[''irqbalance''],
}
$ puppetd --test
does start the service (expected)
$ puppetd --test --tags irqbalance
*does not* start the service (unexpected)
why is this?
If I change the service (added hasstatus) to
service { ''irqbalance'':
ensure => running,
enable => true,
hasstatus => true,
require => Package[''irqbalance''],
}
$ puppetd --test --tags irqbalance
*does* start the service (expected)
--
Kind Regards, Markus Falb
On May 12, 11:09 am, Markus Falb <markus.f...@fasel.at> wrote:> I have a class irqbalance with a service defined and it does not work as > expected and thats why I am asking for advice. > > service { ''irqbalance'': > ensure => running, > enable => true, > require => Package[''irqbalance''], > > } > > $ puppetd --test > does start the service (expected) > > $ puppetd --test --tags irqbalance > *does not* start the service (unexpected) > why is this?Prior to Puppet 2.7, if a Service resource does not have "hasstatus => true" then Puppet will check its status by looking for its name in the process table. (In Puppet 2.7 the default for this parameter changed, so you need to explicitly set hasstatus => false to get the table lookup behavior.) I speculate that you are running something older than 2.7 (so probably 2.6.x), and that when Puppet scans the process table to check whether irqbalance is running, it matches on your Puppet command line "puppetd --test --tags irqbalance".> If I change the service (added hasstatus) to > > service { ''irqbalance'': > ensure => running, > enable => true, > hasstatus => true, > require => Package[''irqbalance''], > > } > > $ puppetd --test --tags irqbalance > *does* start the service (expected)And since your initscripts support it, that''s the way you should have declared the service all along. It''s much more reliable, which I guess is why it became the default in 2.7. 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.
On 14.5.2012 14:53, jcbollinger wrote:> On May 12, 11:09 am, Markus Falb <markus.f...@fasel.at> wrote: >> I have a class irqbalance with a service defined and it does not work as >> expected and thats why I am asking for advice. >> >> service { ''irqbalance'': >> ensure => running, >> enable => true, >> require => Package[''irqbalance''], >> >> } >> >> $ puppetd --test >> does start the service (expected) >> >> $ puppetd --test --tags irqbalance >> *does not* start the service (unexpected) >> why is this? > > > Prior to Puppet 2.7, if a Service resource does not have "hasstatus => > true" then Puppet will check its status by looking for its name in the > process table. (In Puppet 2.7 the default for this parameter changed, > so you need to explicitly set hasstatus => false to get the table > lookup behavior.) > > I speculate that you are running something older than 2.7 (so probably > 2.6.x), and that when Puppet scans the process table to check whether > irqbalance is running, it matches on your Puppet command line "puppetd > --test --tags irqbalance".Uh. I read about that change but I was not clear about the consequences. This would mean that looking in the process table is unreliable and now I am thinking about setting a default Service { hasstatus => true } so I do not have to specify it for every service. Thanks -- Kind Regards, Markus Falb
On May 14, 12:07 pm, Markus Falb <markus.f...@fasel.at> wrote:> This would mean that looking in the process table is unreliableIndeed so. It is the least common denominator, but as you saw, it is prone to false positives. In some cases it can also suffer from false negatives.> and now > I am thinking about setting a default > > Service { > hasstatus => true > > } > > so I do not have to specify it for every service.That''s entirely reasonable if your initscripts support it. While you''re at it, you might consider whether you should also default "hasrestart => true". If any of your initscripts do not support one or both of those commands, I recommend explicitly specifying appropriate commands in those Services'' ''status'' and ''restart'' parameters instead of relying on the default behavior. 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.
On 14.5.2012 19:48, jcbollinger wrote:> > On May 14, 12:07 pm, Markus Falb <markus.f...@fasel.at> wrote: > >> and now >> I am thinking about setting a default >> >> Service { >> hasstatus => true >> >> } >> >> so I do not have to specify it for every service. > > > That''s entirely reasonable if your initscripts support it.Understood! But, Hmm. What if I want to make my module public? I can not know if another ones initscripts supports hasstatus and I cannot guess another ones puppet version. How would you deal with this issue in modules made public? -- Kind Regards, Markus Falb
On May 14, 2:31 pm, Markus Falb <markus.f...@fasel.at> wrote:> On 14.5.2012 19:48, jcbollinger wrote: > > > > > On May 14, 12:07 pm, Markus Falb <markus.f...@fasel.at> wrote: > > >> and now > >> I am thinking about setting a default > > >> Service { > >> hasstatus => true > > >> } > > >> so I do not have to specify it for every service. > > > That''s entirely reasonable if your initscripts support it. > > Understood! But, Hmm. What if I want to make my module public? I can not > know if another ones initscripts supports hasstatus and I cannot guess > another ones puppet version. > > How would you deal with this issue in modules made public?First, I would avoid putting top-level resource default declarations into a module intended to be shared, as their scope would extend beyond the module. If you want module-wide resource defaults, however, then create a master class for your module, put the defaults inside it, and make it (afterward) include any other needed classes. As far as choosing the correct OS(version)-specific default values within your module, I would define such values in a class or in a hiera data store, keyed one way or another to the OS (and maybe OS version). If you want to re-use the OS-specific data across multiple modules then you could split it out into its own module. 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.