https://www.puppet.com/community logo
Join Slack
Powered by
# puppet
  • j
    it's a centos 7 systemd unit file ... it does have an 
    ExecReload=/bin/kill -s HUP ...
    line
  • n
    To answer your question directly jms1, no. There isn't a way to change what kind of refresh signal is sent. The only thing you can affect in Puppet is which resource gets told to refresh.
  • j
    hence the 
    exec
    which runs a 
    systemctl reload
    command
  • n
    yup
  • c
    can you nab some of the 
    flags =>
    feature some kind of way?
  • b
    we do that in consul? as well. reload for some changes, restart for other changes
  • j
    so there's no way to make puppet only run the exec if the service isn't being restarted in the same agent run?
  • j
    not familiar with 
    flags =>
    ... did that exist in puppet 4.5.2? (yes, i'm still stuck in the stone ages)
  • n
    It comes down to organizing your classes/resources so that the ones that need a full restart refresh the 
    service
    , and ones that only need a reload refresh the 
    exec
    . And then you have to live with the fact that you might get a 
    restart
    followed by a 
    reload
    . Which, if the service being reloaded is written well, that extra 
    reload
    at the end shouldn't be a problem.
  • n
    But , I agree, it's uneccessary. And I haven't ever found a way around that problem, personally.
  • n
    But , I agree, it's uneccessary. And I haven't ever found a way around that problem, personally.
  • c
    allthethings Exec ALL THE THINGS
  • j
    it's that "restart followed by a reload" that i'm trying to avoid ... i personally don't care much, but somebody else noticed it happening once and created a ticket about it, and now every few weeks, if the ticket review meeting gets that far down on the list, i have to explain "not a big deal" again, but manglement doesn't want to "just close the damn ticket already" 😛
  • n
    Maybe the exec could run an 
    onlyif
    script that checks the lifetime of the systemd service. If it's less than x seconds, don't reload. But that creates new problems, so I'm not sure I'd do that.
  • n
    Maybe the exec could run an 
    onlyif
    script that checks the lifetime of the systemd service. If it's less than x seconds, don't reload. But that's not fool proof.
  • n
    Maybe the exec could run an 
    onlyif
    script that checks the lifetime of the systemd service. If it's less than x seconds, don't reload. But that creates new problems, so I'm not sure I'd do that.
  • j
    that's an awesome idea, i just wrote that down ... let me know if you're ever in sarasota, i owe you a grown-up beverage of your choice
    🥛 1
    🍻 1
    ☕ 1
  • s
    This message was deleted.
    n
    j
    • 3
    • 5
  • r
    I've done tweaks like this in past for squid where when acls update we want to reload, but restart when config files change. Set the service to reload by default, add a restart exec in a class and decide when to trigger it. IME most things in Apache should trigger the restart so might be hard to handle all restart cases.
    Copy code
    class squid {
  include squid::install, squid::config, squid::service, squid::restart
  Class['squid::install']
  -> Class['squid::config']
  ~> Class['squid::service']
  -> Class['squid::restart']
    Copy code
    class squid::config { 

  file { '/etc/squid/squid.conf':
    content => template(squid/squid.conf.erb),
    notify => Class['squid::restart'],
  }

  file { '/etc/squid/acls.conf':
    content => template(squid/squid.acl.erb),
  }
}
    Copy code
    class squid::restart {
  exec { 'squid restart': command => 'service squid restart', refreshonly => true, }
}
  • j
    If there are multiple collectors trying to match the same thing, that would make sense.
  • n
    I always explained it as a "second pass over the compiled catalog", which I'm not sure if that's technically correct, but it's close enough to conceptulaize.
  • n
    I always explained it as a "second pass over the catalog", which I'm not sure if that's technically correct, but it's close enough to conceptulaize.
  • v
    one can look into PE code for good ideas 😎 they have restarts and real-restarts 🙂
  • j
    what i was looking for is something like "don't actually do a reload if you're also doing a restart"
  • r
    Yeah I saw that, but seems relatively benign rather than the other way around. The other option might be to switch ssl certs to symlink certname.crt -> certname.crt.2024 or whatever, agree through convention to not change the name in the config, and handle the reload.
  • n
    Seems to me like what you're really after is a way to get your coworkers to trust that the restart + reload thing isn't a problem, and to stop them from making tickets about it. To that end, what if you flip the order and make it so that puppet would only ever do a reload + restart? For example, by ordering the 
    exec
    "before" the 
    service
    . So if both get refreshed, Puppet would reload first then restart.
  • n
    Which to me seems like less of a problem? maybe.
  • v
    Copy code
    service { $stuff:
    hasrestart => true,
    restart    => "systemctl reload ${stuff}.service",
  }
  exec { "${stuff} service full restart" :
    command     => "systemctl restart ${stuff}.service",
    refreshonly => true,
    onlyif      => "systemctl is-active ${stuff}.service",
    before      => Service[$stuff],
  }
  • j
    honestly, i'm trying to get those particular cow-orkers to stop assuming that everything they see but don't understand is actually a problem.
  • n
    That problem never goes away 🙂
1...268269270...428Latest