Comment by esaym | Hacker News Reader

Comment by esaym | Hacker News Reader

Ten years ago when I was I trying to learn how to "program", I wrote this bash script (to be added into /etc/cron.daily) that dumps a few smart stats that are normally 0 or slow changing, diffs it with the copy from the previous run, and if anything is different (and cron in configured right) it will email you the diff. Every linux machine I touch gets this file dropped onto it. I've replaced many hard drives because of it

    #!/bin/bash
    
    
    smartctl -a /dev/sda > /root/smartStates
    grep Reallocated_Sector_Ct /root/smartStates > /root/stats
    grep Current_Pending_Sector /root/smartStates >> /root/stats
    grep Offline_Uncorrectable /root/smartStates >> /root/stats
    grep UDMA_CRC_Error_Count /root/smartStates >> /root/stats
    
    touch /root/statsOld
    cmp /root/stats /root/statsOld
    result=$?
    
    if [[ $result -ne "1" && $result -ne "0" ]]
      then
    	echo "Something went wrong"
    	exit -1
    fi
    
    if [[ $result -eq "1" ]]
      then
    	echo "Files are different\n"
    	cat /root/stats
    fi
    
    mv /root/stats /root/statsOld
    rm /root/smartStates

I'm not sure why you wouldn't use smartd, which has sane defaults, can immediately alert based on arbitrary smart properties changing, and also handles scheduling smart tests. An arbitrary command can be run instead of sending email.

For example, reallocated sectors are not alerted on by default, so we added '-R 5!' to our smartd config. The full config we have is:

DEVICESCAN -a -s (L/../../6/01) -l selftest -l error -m <email> -M daily -M test -R 5!

My familiarity with SMART was on the POST screen. I never ran any daemons; I didn't know they were a thing. Like so many other nerds that grew up in the 90s, we've all experienced data loss. At the best it was just some porn and the worst were those rare VHS tapes you ripped of random high school crap.

I feel like there were enough tools for users to simply monitor SMART stats, or awareness of how it works. Even in this article, it seems like a lot of analysis to see if reported flags are significant.

(Warning pedantic script review)

Add a "set -e" to catch errors. Say if the disk can't be read or file can't be written.

Why reuse the same temp file? Make a new one with mktemp and auto clean it via an exit trap. As it's written this isn't concurrently safe.

Exiting -1 on error? Don't use negatives.

Wrap it all in a main() function and use locals instead of global vars.

You don't even need the 'smartStats' temporary file at all, since you can do that with just one grep:

  smartctl -a /dev/sda |
    grep '\(Reallocated_Sector_Ct\|Current_Pending_Sector\|Offline_Uncorrectable\|UDMA_CRC_Error_Count\)' > /root/stats

awk is probably better in this case, since you can save only the raw values (and other columns that you deem important):

   awk '/Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count/ {print $2,$10}'

It's just a small bash script, and one that's apparently worked well for 10 years. Rewriting it to J2EE standards would just be a waste of time; the best outcome is that it still works the same, and the other outcome is that you introduced a new bug refactoring it.

> It's just a small bash script, and one that's apparently worked well for 10 years. Rewriting it to J2EE standards would just be a waste of time; the best outcome is that it still works the same, and the other outcome is that you introduced a new bug refactoring it.

I don't see how following best practices for bash scripting (or really shell scripting in general) can be compared to J2EE standards.

Seek quality in all your scripting so it becomes the norm. Otherwise you'll end up having crap like that in something mission critical.

Also https://www.shellcheck.net/

This is basically what smartmontools does:

    /var/log/syslog:Oct  6 08:14:10 hostname smartd[573]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 61 to 62
    /var/log/syslog:Oct  6 09:44:10 hostname smartd[573]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 62 to 61
    /var/log/syslog:Oct  6 10:14:10 hostname smartd[573]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 61 to 60
    /var/log/syslog:Oct  6 18:44:10 hostname smartd[573]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 60 to 59

I respectfully disagree. Judging from the output you posted, it just spams logfiles with irrelevant info, training the user to ignore it, so they will never notice when important values change in an interesting way.

Really?

My hard disks are fine, so right now the only stat changing is that, so that's what `rgrep smartd /var/log` turned up, so that's what I posted.

Did you consider looking at `man smartd.conf`? Did you consider that reporting and logging the temperature is entirely optional? Did you consider that you can configure it to log and report and email warnings for exactly the stats that you want? Did you consider that, for example, the stock Debian/Ubuntu package will pop up a window in your X session when stats which actually indicate potential failure change, like sector reallocations, read errors, etc?

Nah, just jump to the conclusion that all it does is spam logs with temperature readings, and downvote away!

Did you keep any data on how often you got to replace your drives because of such signs ?

Now you can just `apt install smart-notifier`

Looks useful

How about: a comment on (1) what this bash script does, (2) and why, and (3) the reason for dumping a disk as a result.

1) How about read the script. 2) How about read the subject 3) How about understanding it.

Reply on news.ycombinator.com