Add SMART monitor config options to howto

[phillxnet]

Thanks to forum member dcbailey for highlighting this issue: New in v4 is the default to not monitor all devices. We already have a tooltip/mouse-over popup in the configuration area of the SMART service entry but it would be good to add a new section to our existing SMART howto to show how to enable common options such as:

DEVICESCAN -a

I.e.:

We also have a new sensitivity to virtualisation but that should be addressed in it's own doc issue.

[Hooverdan96]

@phillxnet, so if I understood this correctly from the forum thread:

• in general, there is no need to add a directive
• however, there are some instances/hardware configurations where the out-of-the-box smartd service is not recognizing/monitoring the devices correctly.
• To address these exceptions, a directive can be added to the smart Daemon, i.e. DEVICESCAN -a to ensure that all possible errors are monitored on all attached disks that Rockstor recognizes

Is that in a nutshell what should be added to the How-to? Where do you think this belongs in the How-to? After the Custom Options (or within it)?

[phillxnet]

@Hooverdan96 Thanks for the interest here. Re:

• in general, there is no need to add a directive Actually if one wants automated monitoring the addition of say "DEVICESCAN -a" is now a requirement. It seems our new upstream default settings no longer contains this.

• however, there are some instances/hardware configurations where the out-of-the-box smartd service is not recognizing/monitoring the devices correctly.

This is likely still the case, as it has been in the past, but for each problematic device we already have custom smart options to cover this; applied to the specific device. Or we could advise on ignoring certain devices. But not sure how one does this.

• a directive can be added to the smart Daemon, i.e. DEVICESCAN -a to ensure that all possible errors are monitored on all attached disks that Rockstor recognizes

This looks now to be a requirement. Our other on-the-spot smart features still work as before, i.e. when clicking on a device name and doing a refresh of the smart data. But as per v4 the default config is to monitor nothing by default. That is my current understanding. Likely to avoid log spamming. We also have the additional caveat of the virtualisation sensitivity where our upstream disables smartd in VM environments but that can be handled independently as it's not directly related.

My apologies for likely not being clear here. But in short we now need some intentional config added, likely "DEVICESCAN -a" to achieve any automated monitoring at all. But we also should advise the email notifications in consort so folks will receive emails of any events logged.

Where do you think this belongs in the How-to?

Given it's now required, and a global setting of sorts, I think this should be the first section after our disk snapshot smart readings. I.e. a new section directly before the custom options. I.e.:

• S.M.A.R.T (existing pics and associated text) -- Configure Monitoring (new section) -- Disk Custom S.M.A.R.T Options -- Add Drive Specific Custom S.M.A.R.T Options -- S.M.A.R.T through Hardware RAID Controllers

Where in the new section "Configure Monitoring" we point to our existing tooltip popup and maybe add a link to upstream docs. Along with a picture of our suggested default addition of "DEVICESCAN -a".

I think the new section directly, after our real-time via "Refresh" button pics etc, is the way to go. As they work out of the box and no all folks will want monitoring. Especially if it ends up spamming their logs out-of-the-box. Hence we now favour an explicit configuration but documented. Not quite as nice as having by default but it's our new upstream default and we want to keep our second-guessing to a minimum. I don't think there is any need to specify v4 vs v3 anymore either. Plus there is no harm in 2 of these config entries anyway.

We need to establish for sure how the email notifications work with this. I.e. if we need to add an email directive to that command or not. So that enabling email notifications ties in as expected. It can work as I've configured this myself but it was a while ago and I'm not sure now. Plus we have made some improvements in email sending re notifications so we either need nothing else and smartd sends notifications to the root user via local email and they are auto forwarded when email notifications are enabled, or we need to add a root email directive. Best go via root@localhost at this level of config (in smartd), if needed, as we then substitute domain 'from' accordingly in the email notifications config later. According to what folks configure in the email notifications.

Does that sound clearer. That's my current findings/understanding. I.e. current default config is essentially empty bar excluding removable type devices form what I can tell. Hence the forum report that there are no devices to monitor, once we dug into the error reports that is.

Hope that helps. Do have a play as I may have this all wrong but from looking at the report and the config file it does now look like we have an essentially empty config as our upstream default.

[phillxnet]

An related element of this issue should be the addition of a S.M.A.R.T entry in on our services page: https://rockstor.com/docs/interface/system/services.html

This could in turn link to the suggested additional more detailed entry on this services configuration suggested above, within our more focused S.M.A.R.T section/howto: https://rockstor.com/docs/howtos/smart.html

[Hooverdan96]

@phillxnet. check it out.

I was able to send a mail to the root@localhost without doing anything else and retrieve it, so not sure whether the spool directory was already there or not, but given that all other manually created users seem to have it there, it should not pose a problem...

[phillxnet]

@Hooverdan96 Re:

I was able to send a mail to the root@localhost without doing anything else

Super, which should mean, in combination with our email alerts, this gets forwarded. Nice.

... it should not pose a problem...

Agreed. We can pretty much assume this as it's a base user setup thing. And our alerts just forward 'local' system email to the configured external email system.