Running a daemon only during certain hours of the day

[Gabriel Filion]

Hello,

A client of mine needs to be able to control which hours during the day
a certain daemon is running and which hours it is not.

So far I can think of hiera for controlling the on/off periods + some
math magic to determine in the puppet manifests whether we are currently
in the On or Off period (which would ensure either "running" or "stopped").

The other option could be a custom fact (which would make manifests less
complicated), but I'm unsure of how control over the on/off time periods
could be achieved in this case.

Am I more or less on to something with the above or am I trying to do
something with the wrong tool? One of the downsides of using puppet is
that runs are only once per hour (in that case) so the starting and
stopping times might be unreliable :\

--
Gabriel Filion

[Peter Bukowinski]

On Apr 9, 2015, at 1:26 AM, Gabriel Filion <gab...@lelutin.ca> wrote:
>
> Hello,
>
> A client of mine needs to be able to control which hours during the day
> a certain daemon is running and which hours it is not.
>
> So far I can think of hiera for controlling the on/off periods + some
> math magic to determine in the puppet manifests whether we are currently
> in the On or Off period (which would ensure either "running" or "stopped").

This seems like an overly-complex approach.

> The other option could be a custom fact (which would make manifests less
> complicated), but I'm unsure of how control over the on/off time periods
> could be achieved in this case.
>
> Am I more or less on to something with the above or am I trying to do
> something with the wrong tool? One of the downsides of using puppet is
> that runs are only once per hour (in that case) so the starting and
> stopping times might be unreliable :\

Puppet is really good at managing steady states. Why not have puppet manage cron entries responsible for starting and stopping the daemon? A custom fact could be used to return the current on/off state (accurate as of the last puppet run, or course) of the daemon for auditing purposes.

--
Peter

[Chad Huneycutt]

I am not necessarily condoning this, but puppet has a "schedule"
metaparameter that can control when a resource may be managed. That
would solve half the problem. You could probably manage it in the
other state using the same trick, but you have to "trick" puppet by
giving the resource another name.

- Chad

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55260D86.2070200%40lelutin.ca.
> For more options, visit https://groups.google.com/d/optout.



--
Chad M. Huneycutt

[Gabriel Filion]

On 09/04/15 02:01 AM, Peter Bukowinski wrote:
> On Apr 9, 2015, at 1:26 AM, Gabriel Filion <gab...@lelutin.ca> wrote:
>> A client of mine needs to be able to control which hours during the day
>> a certain daemon is running and which hours it is not.
>>
>> So far I can think of hiera for controlling the on/off periods + some
>> math magic to determine in the puppet manifests whether we are currently
>> in the On or Off period (which would ensure either "running" or "stopped").
>
> This seems like an overly-complex approach.

right

>> The other option could be a custom fact (which would make manifests less
>> complicated), but I'm unsure of how control over the on/off time periods
>> could be achieved in this case.
>>
>> Am I more or less on to something with the above or am I trying to do
>> something with the wrong tool? One of the downsides of using puppet is
>> that runs are only once per hour (in that case) so the starting and
>> stopping times might be unreliable :\
>
> Puppet is really good at managing steady states. Why not have puppet manage cron entries responsible for starting and stopping the daemon? A custom fact could be used to return the current on/off state (accurate as of the last puppet run, or course) of the daemon for auditing purposes.

ah yes, I actually had thought about this but forgot to mention it. this
would be actually more reliable time-wise.

my only concern would then be if the service crashes during the "on"
period or gets started by someone for any reason in the "off" period and
forgotten there. puppet would add a safety net by ensuring the service's
state.. I'll have to verify if this can be possible and/or a concern
before I try to fix this part.

thanks for the input.

--
Gabriel Filion

[Dan White]

What about setting the state of the service based on clock time ?
It would depend on how often puppet runs.

The cron suggestion would complement this in a nice "belt-and-suspenders" solution.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5526CF07.6060502%40lelutin.ca.

[Peter Kristolaitis]

On 04/09/2015 03:12 PM, Gabriel Filion wrote:
>> Puppet is really good at managing steady states. Why not have puppet manage cron entries responsible for starting and stopping the daemon? A custom fact could be used to return the current on/off state (accurate as of the last puppet run, or course) of the daemon for auditing purposes.
> ah yes, I actually had thought about this but forgot to mention it. this
> would be actually more reliable time-wise.
>
> my only concern would then be if the service crashes during the "on"
> period or gets started by someone for any reason in the "off" period and
> forgotten there. puppet would add a safety net by ensuring the service's
> state.. I'll have to verify if this can be possible and/or a concern
> before I try to fix this part.
>
> thanks for the input.
>

Set your cron jobs to run every minute during the period, so that the
service will be running (or not) for at most 1 minute after a
human-error / crash / reboot / deploy-new-node-due-to-auto-scaling
event. Yes, it's kind of brute-force-ish, but the overhead to check a
service's state and start/stop it isn't that high.

If the goal is to make sure that the service is or is not running during
certain time periods, would you rather wait an hour for a Puppet agent
run or a minute for a cron job?

- Peter