FAQ
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

Search Discussions

  • Jcbollinger at May 14, 2012 at 12:53 pm

    On May 12, 11:09 am, Markus Falb 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.
  • Markus Falb at May 14, 2012 at 5:07 pm

    On 14.5.2012 14:53, jcbollinger wrote:
    On May 12, 11:09 am, Markus Falb 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
  • Jcbollinger at May 14, 2012 at 5:49 pm

    On May 14, 12:07 pm, Markus Falb wrote:
    This would mean that looking in the process table is unreliable

    Indeed 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.
  • Markus Falb at May 14, 2012 at 7:32 pm

    On 14.5.2012 19:48, jcbollinger wrote:
    On May 14, 12:07 pm, Markus Falb 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
  • Jcbollinger at May 15, 2012 at 1:12 pm

    On May 14, 2:31 pm, Markus Falb wrote:
    On 14.5.2012 19:48, jcbollinger wrote:


    On May 14, 12:07 pm, Markus Falb 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 12, '12 at 4:10p
activeMay 15, '12 at 1:12p
posts6
users2
websitepuppetlabs.com

2 users in discussion

Jcbollinger: 3 posts Markus Falb: 3 posts

People

Translate

site design / logo © 2022 Grokbase