[FEAT] Allow manual configuration of cron task which runs metrics collector

[teambvd]

Is your feature request related to a problem? Please describe.
Temperature monitoring should be taken at more regular intervals than every 24 hours. The baked in cron job for this docker image only allows for polling every 24 hours.

Describe the solution you'd like
An update to allow for configurable cron. For docker, a variable called 'SCHEDULE', which accepts cron-style input. i.e. I wish to have metrics collected every 6 hours, so my docker run would look like:

docker run -it --rm -p 8080:8080 \
-v /run/udev:/run/udev:ro \
-e SCHEDULE:0 0/2 * * *\
--cap-add SYS_RAWIO \
--device=/dev/sda \
--device=/dev/sdb \
--name scrutiny \
analogj/scrutiny

Additional context
Allowing the docker image users the same flexibility as those doing a bare install would be fantastic

[AnalogJ]

This is a fantastic idea. Let me take a look at the Jobber config and see how hard this would be to implement.

[teambvd]

Shouldn’t be too bad I’d assume? I know frick all about containerized coding, but use the same tactic pretty regularly for python where I need a unique identifier for reports generated... for instances where you don’t care what the hell its “named”, so long as you can come as close as possible to guaranteeing there’s nothing else (anywhere) using that same name.

…

On Sat, Oct 3, 2020 at 8:45 PM Jason Kulatunga ***@***.***> wrote: This is a fantastic idea. Let me take a look at the Jobber config and see how hard this would be to implement. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQW5ULQVUIPEQ65WCV24VKTSI7HTVANCNFSM4R6IMBJQ> .

[AnalogJ]

I've since replaced Jobber with Cron. The crontab file is located at /etc/cron.d/scrutiny. However, it has some eccentricities unique to Scrutiny (/env.sh and STDOUT/STDERR redirects). Since cron/crontab does not support dynamic schedules, I think we would have to use something like confd to generate the config at runtime.

Though, now that I think about this further, we could use s6-overlay init functions for the omnibus image, and just a bash HEREDOC file for the collector-specific image.
hm.