Scripts to report SMART, ZPool and UPS status, HDD/CPU T°, HDD identification and backup the config

[Osiris]

Found these aeons too late.
Thanks for sharing the scripts.
I had a short one that just shows me name, serials, gpt, disksize

 

[Bidule0hm]

I modified the Zpool script to fix a problem in the errors parser.

I also changed everything that needed to be changed to make the script POSIX compliant.

 

[Bidule0hm]

I modified the SATA version of the SMART script to add the warning symbol when the last test age is over the testAgeWarn value.

I also changed everything that needed to be changed to make the script POSIX compliant.

 

[Bill McCormick]

I'd like to get started with this, but I'm stuck on where to locate the scripts. My freenas box doesn't have a /home and my account home dir is set to /nonexistent. Can I safely mkdir /home & mkdir /home/user & mkdir /home/user/scripts? I was under the impression that when I to a Freenas update, anything other than pools under /mnt will get blown away. Is that not true?

Also, if I wanted to use Perl for this, what would be the implications?

There exists a Perl module called Disk::SMART that is active.
use Disk::SMART;

my $smart = Disk::SMART->new('/dev/sda', '/dev/sdb');

my $disk_health = $smart->get_disk_health('/dev/sda');

... and so on.

 

[Bidule0hm]

I don't recommend at all to create /home like that. The safer way to put your scripts is to create a dataset (linux type, not windows type) called scripts for example and not share it. Then you can put your script in /mnt/your_pool/scripts/ ;)

Please note that a lot of the scripts needs root rights so if you create it with another user don't forget to use root to execute them if they doesn't work with the user account.

I don't know about Perl, I never wrote one line of Perl...

 

[Bill McCormick]

I thought the idea was to NOT put the scripts in the pool, less they not be accessible when needed?

 

[joeschmuck]

Why would the scripts not be accessible if they are part of the pool? Are you planning to sleep the drives?

 

[Bidule0hm]

That's why I put them in /root but I'm on the paranoid side...

I still recommend to put them on the pool because it's simpler and less prone to mistakes (i.e. you'll not damage the system by error) ;)

 

[Bill McCormick]

Why would the scripts not be accessible if they are part of the pool? Are you planning to sleep the drives?

I'm still kind of new to all of of this NAS stuff and I'm not really up on harddrive tech. So I'm not even sure what the default drive behavior is. I thought maybe sleeping is something that happens by default.

I suppose I'm just operating on instinct; better to have that which is doing the diagnostics separate from what it is diagnosing.

So if storing and running the scripts from the pool is no issue, maybe doing all from a jail would be even better?

 

[joeschmuck]

By default the drives will not sleep and the majority here will tell you to not sleep the drives. That doesn't mean you can't sleep the drives, well most of them, but there are considerations and specific setups to do in order to allow the drives to sleep. My drives have been running for the most part non-stop for over 3 years, not a single problem with them.

I prefer to have all my scripts under /mnt/pool/scripts or something similar. I also create the subdirectory via the CLI so it is not visible in the GUI because I do not want it to be accidentally deleted. I know it's there so I don't need to see it in the GUI. I make this while logged in as root and all the permissions fall into place. See my link in the first posting in this thread for step by step directions on how to do these things, or at least see another way of doing it. And having your scripts on the pool is a much safer place to keep them. Why you ask? 1) You are not messing around with the boot device. 2) If you have a corrupt boot device, when you rebuild it will all your scripts be dust?, 3) The scripts may not survive a software update (very possible).

Hope this answers your questions.

 

[Bidule0hm]

Yep, it's basically "better to have that which is doing the diagnostics separate from what it is diagnosing." vs. "1) You are not messing around with the boot device. 2) If you have a corrupt boot device, when you rebuild it will all your scripts be dust?, 3) The scripts may not survive a software update (very possible)."

Pick the solution you prefer, there isn't one right solution and all the others are bad. For beginners I recommend the directory or dataset on the pool solution ;)

 

[Trapizomba]

Hi...

I made a script to alert high temperatures of the HDDs based on S.M.A.R.T.... The goal of my script is to be more hardware independent as possible...

But unfortunately I didn't tested it with SAS disks

Code:

#!/bin/bash

### Define parametros de alerta ###
temp_max=35  # Temperatura em graus celcius
email="seu_endereco_de_email"  # E-mail do destinatario do alerta
assunto="FreeNAS: Alerta de temperatura HDD" # Assunto do email

# Define variavel de graus celcius
CEL=$'\xe2\x84\x83'

# Monta array de discos do sistema
arrdiscs=($(camcontrol devlist | awk '{print substr($NF, 8, length($NF)-8)}'))

# Cria array para alerta de temperatura
alertdiscs=()

# Recupera a temperatura dos discos com base no arrdiscs
for i in "${arrdiscs[@]}"
do
temp=("$(smartctl -A "/dev/$i" | egrep ^194 | awk '{print $10}')")
if [ -n "$temp" ] && [ $temp -gt $temp_max ]; then
alertdiscs+=("[$i]: $temp$CEL")
fi
done

# Compara os valores de temperatura com a variavel temp_max e gera alerta
if [ ${#alertdiscs[@]} -gt 0 ]; then
# Envia email de alerta
printf "%b\n" "Discos com temperatura acima do limite ($temp_max$CEL):\n${alertdiscs[@]}" | /usr/bin/mail -s "$assunto" "$email"
fi

So... No need to define the name of the HDD devices... :)

With this script an email will be send ONLY if the temperature of one or more HDDs is higher than that specified in the max_temp variable. In the message body will be listed only the hard drives with high temperatures.

Hope it help someone... ;)

My script broke after some FreeNAS updates...

So, to make it work again, just replace the "arrdiscs=($(camcontrol devlist | awk '{print substr($NF, 8, length($NF)-8)}'))" line with:

Code:

arrdiscs=($(camcontrol devlist | awk '{print substr($NF, 2, length($NF)-8)}'))

 

[Bill McCormick]

Yea, my drives are pretty busy 24/7. But I'm just getting up and running so I'm not sure about 365. Anyway, I'd be in the let 'em run camp.

All your run-from-the-pool points makes sense. Are there any (negative) considerations when running from the pool? From a jail? Is it only a consideration if you're in the sleep'em camp?

Wouldn't it be YAO (yet another option) to store the scripts on a flash drive and then just configure a cron job to run them? Downside to that?

 

[Bidule0hm]

If the pool fails the scripts can't run, but if you've a failed pool you've a bigger problem than the scripts not running I guess... :)

I'd not run them from the jail, it's useless and probably the jail doesn't have access to everything so the scripts will not work anyway.

You can do that if you mount the USB drive correctly under FreeNAS but it's not a great idea (you waste a USB drive just for a few scripts, mounting USB drives on FreeNAS isn't terribly reliable, ...).

 

[joeschmuck]

Wouldn't it be YAO (yet another option) to store the scripts on a flash drive and then just configure a cron job to run them? Downside to that?

You could do that. You will need to chose what you're comfortable with.

 

[Bill McCormick]

I'd not run them from the jail, it's useless and probably the jail doesn't have access to everything so the scripts will not work anyway.

Help me understand "useless". What more do the scripts need access to other than a functional smartctl?

I like Perl over shell scripting so what I'm leaning toward doing is running Perl scripts from jail. I've already installed the smartmontools-6.4_1 and tested smartctl in a jail; that all seems to work. As for e-mail, there's like a gazillion Perl modules that do mail. What else might I check?

Anyway, before I go off re-inventing the wheel, I'll get the scripts setup and working and see if there might be some advantage to using Perl. If I make something compelling, maybe I can get the powers that be to include the required Perl modules (there would be 3).

Here's a synopsis of the Disk::SMART module if anybody cares: https://metacpan.org/pod/Disk::SMART

 

[Bidule0hm]

Help me understand "useless".

It's useless because the jail doesn't have any advantages.

What more do the scripts need access to other than a functional smartctl?

Just read them, you'll see all the commands ;)

 

[Bill McCormick]

It's useless because the jail doesn't have any advantages.

Maybe we'll have to agree to disagree on this, but if one of the advantages of putting the scripts under /mnt/pool/somewhere is that you don't mess with the OS too much, wouldn't running from a jail just extend that concept, and thus be just as much or even more of an advantage? And if I can install and run any Perl module I want, I think that's an advantage.

If you don't do Perl and don't care to, then sure, the last point is moot. But I'm not sure how you can argue about the first point.

 

[Bidule0hm]

I speak for the scripts in the OP, not for Perl or others scripts. Of course if you need to install a package then don't do it on the system.

 

[Bill McCormick]

I got the scripts working for my /dev/ada drive, but I'll need to make a change to get the /dev/pass drives working.

Probably the easiest thing to do is change smartctl -A -i -v 7,hex48 /dev/"$drive" to smartctl -A -i -v 7,hex48 "$drive" and include the complete device name and extra params in the $drives variable.