[FEAT] Allow to set the time to collect smart data (don't wake up disks just for smart collection)

[zilexa]

Is your feature request related to a problem? Please describe.
My disks are spinned down by default and most of the time. Would be a waste to spin up/down/do a load cycle just for SMART>

Describe the solution you'd like
Allow users to set the time at which the collector will run.
This way, the collector can run when other nightly tasks will be performed.

[BlueCat0]

scrutiny/rootfs/scrutiny/jobber/jobber.yaml

Lines 1 to 30 in 27b923b

	version: 1.4
	prefs:
	logPath: /scrutiny/jobber/log.log
	runLog:
	type: file
	path: /scrutiny/jobber/runlog
	maxFileLen: 100m
	maxHistories: 2
	resultSinks:
	- &filesystemSink
	type: filesystem
	path: /scrutiny/jobber
	data:
	- stdout
	- stderr
	maxAgeDays: 10
	jobs:
	MetricsJob:
	cmd: /scrutiny/bin/scrutiny-collector-metrics run
	# run daily at midnight.
	time: '0 0 0 * * *'
	onError: Backoff
	notifyOnSuccess:
	- *filesystemSink
	notifyOnFailure:
	- *filesystemSink

scrutiny/docker/Dockerfile

Line 41 in 27b923b

COPY /rootfs /

just mount your jobber file to overwrite default file.

[AnalogJ]

Hi
I recently updated both the collector and all-in-one container to use Cron, rather than jobber.
As before, the collector is scheduled to run daily, at midnight. The images now read their cron config from /etc/cron.d/scrutiny, with a default file that looks like the following:

# correctly route collector logs (STDOUT & STDERR) to Cron foreground (collectable by Docker STDOUT)
# cron schedule to run daily at midnight:  '0 0 * * *'
# System environmental variables are stripped by cron, source our dump of the docker environmental variables before each command (/env.sh)
0 0 * * * root . /env.sh; /scrutiny/bin/scrutiny-collector-metrics run >/proc/1/fd/1 2>/proc/1/fd/2

If you would like to change the collector frequency, you can mount your own crontab compatible file, but please include the . /env.sh; prefix when running the collector (it's required to pass docker env vars to the process).

Eventually I'd like to use confd (or something similar) to dynamically generate the crontab so that users could set their Collector cron schedule dynamically, but thats an issue for another day.

[zilexa]

@AnalogJ Sorry just 1 more quick check here. The documentation shows we can do a manual run via:
docker exec scrutiny /scrutiny/bin/scrutiny-collector-metrics run

Although I am using the all in one Docker image, this seems to work, there are no env vars in the example docker-compose.

Am I missing the importance of ./env.sh?

[AnalogJ]

Hey @zilexa
Sorry, it seems I was a bit overzealous closing this issue. You're correct, even with the cron replacement, there's currently no way to customize the cron schedule for the collector, without manually mounting a new crontab file.

[somebody-somewhere-over-the-rainbow]

@zilexa

I am in a similar situation - is simply mounted crontab file without any jobs to /etc/cron.d/scrutiny inside the container to disable the midnight collector job and then added docker exec scrutiny /scrutiny/bin/scrutiny-collector-metrics run at the end of my nightly script. That way it is always running when all of my disks are spun up and provide temperature value after they did some work ;-)

[somebody-somewhere-over-the-rainbow]

@AnalogJ thanks for the awesome work! ideally there would also be setting in the yaml (or gui) to not wake up disks to collect values (e.g. paired with the option collect hourly to actually get values at some point) -

[zilexa]

@alexw1982 I now run Scrutiny manually via a bash script on the host system right after a nightly backup run.
Since a backup run will spin up all disks, this moment makes most sense.

The only issue I run into is I use Hotio's Scrutiny image (only 87MB since it shares components with other Hotio images) but it doesn't provide an easy way to disable it's interval run. Nothing AnalogJ can do about that.

[ljmerza]

Do i still need to add my own crons to get the SMART tests to run on my disks or does Scrutiny do that as well?

[mpfl]

Another option would be to use a container-native scheduler like chadburn.

I'm using it with a photo management container to schedule automatic imports of new photos that are occasionally uploaded to a particular directory.