Hard disk monitoring tools

Bug #16386 reported by John Moser
36
This bug affects 1 person
Affects Status Importance Assigned to Milestone
smartmontools (Ubuntu)
Fix Released
Wishlist
Unassigned
Nominated for Lucid by Alex Mayorga

Bug Description

As mentioned by somebody on the devel mailing list, but apparently never bugged
here, smartmontools could be used to construct a graphical UI program that
monitors the hard disk and warns of imminent failure.

The tool should sit in the system tray and spin idle. Every so often it should
do an offline smart long test on all hard drives. There should also be
controlled on-demand scanning.

 - Tool starts on log-in by default
 - Tool communicates with a daemon
 - Daemon communicates with smartmond
 - Daemon allows offline tests without rootauth -- offline tests suspend on any
command, so are mostly harmless
  - Offline tests w/o auth should be restricted to one every 24 hours! (to
prevent malicious motor burn-out or whatnot; though constant find / and cat can
do the same thing)
 - Daemon automatically performs tests at configured intervals -- default 7 days
 - Tools need no auth to get SMART status
 - Tool sits in tray with indicator icon -- idle, testing, alert
  - Alert should take advantage of any future feature of Gnome that allows for
hiding of inactive systray icons (like in XP) to become visible
  - Alert should appear whenever a drive is failing or expected to fail!

This would facilitate the same functions as existing offline utilities such as
Western Digital Drive Fitness Test or other things, without booting off Ultimate
BootCD or floppy

Revision history for this message
Matt Zimmerman (mdz) wrote :

A feature specification is in progress here:
http://udu.wiki.ubuntu.com/SMARTMonitoring

Revision history for this message
towsonu2003 (towsonu2003) wrote :

I can't find any specs for this: https://features.launchpad.net/distros/ubuntu/+specs?searchtext=smart

wiki page Mr. Zimmerman gave is no longer valid.

Changed in smartmontools:
status: Unconfirmed → Confirmed
Revision history for this message
Mathias Gug (mathiaz) wrote :

Thanks for your report. Your idea might get more attention and have the possibility of being implemented if you submit a specification for it. First check whether the idea is already registered https://launchpad.net/ubuntu/+specs, and if so, contact the specification's drafter about your ideas. Otherwise, you can start writing a spec yourself. https://wiki.ubuntu.com/FeatureSpecifications

The wiki page mentioned by Matt can be found at https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/SMARTMonitoring.

Revision history for this message
trollord (trollenlord) wrote :

I did some hacking on this area. Observations:
- Libnotification -style popups are nearly perfect for signaling an average Joe of an upcoming problem.
- Best way would be to notify all the users via dbus.SystemBus() and notification-daemon. However for security etc reasons notification-daemon does not listen on System bus.
- There doesn't seem to be any other plausible way (from besides what I did) of root'd daemons signaling all users available, at least to me.
- Root priviledges are not required for all operations but it makes my solution quite nicely doable.
- Running a daemon for all the logged on users is silly waste of resources.
- Not running smartd might cause delays in noticing errors OR it will consume (a tiny amount) of resources if you poll manually with smartctl.
- SMARTD itself detects on modern computers /dev/sd* as "scsi" and fails utterly. 99% of the brand new hardware uses SATA(2), which actually requires -d ata parameter! This is a *MAJOR* bug in smartd. The way I see around it is to regenerate smartd.conf smartly before starting it up with an other script. OR, submit a bug to upstream and wait until 2050 or so for it to get fixed. I'd make an other python or shell script myself, run it at /etc/init.d/smartmontools start right before trying to start smartd.
- My solution seems to be working for me, and would take only a little bit of further development to be ready for inclusion in default Ubuntu installations.

The solution that actually works is:
- Fix the sata/scsi/ata problem, I did it manually myself!
- Use a "mailer script" that smartd knows how to run when problems arise, -M exec smart-alerter.py (you put that stuff to smartd.conf)
- The script gets automatically that smart problem information via environment variables that smartd sets
- The script finds out what users are potentially "real"
- ... forks once for all of them
- ... uses dbus to send notification, it really actually works awesomely AND is with tiny adjustments usable also by KDE/XFCE etc
- ... dies.

It is simple, passive, working. Comments from some real developers?

Revision history for this message
trollord (trollenlord) wrote :

I did some hacking on this area. Observations:
- Libnotification -style popups are nearly perfect for signaling an average Joe of an upcoming problem.
- Best way would be to notify all the users via dbus.SystemBus() and notification-daemon. However for security etc reasons notification-daemon does not listen on System bus.
- There doesn't seem to be any other plausible way (from besides what I did) of root'd daemons signaling all users available, at least to me.
- Root priviledges are not required for all operations but it makes my solution quite nicely doable.
- Running a daemon for all the logged on users is silly waste of resources.
- Not running smartd might cause delays in noticing errors OR it will consume (a tiny amount) of resources if you poll manually with smartctl.
- SMARTD itself detects on modern computers /dev/sd* as "scsi" and fails utterly. 99% of the brand new hardware uses SATA(2), which actually requires -d ata parameter! This is a *MAJOR* bug in smartd. The way I see around it is to regenerate smartd.conf smartly before starting it up with an other script. OR, submit a bug to upstream and wait until 2050 or so for it to get fixed. I'd make an other python or shell script myself, run it at /etc/init.d/smartmontools start right before trying to start smartd.
- My solution seems to be working for me, and would take only a little bit of further development to be ready for inclusion in default Ubuntu installations.

The solution that actually works is:
- Fix the sata/scsi/ata problem, I did it manually myself!
- Use a "mailer script" that smartd knows how to run when problems arise, -M exec smart-alerter.py (you put that stuff to smartd.conf)
- The script gets automatically that smart problem information via environment variables that smartd sets
- The script finds out what users are potentially "real"
- ... forks once for all of them
- ... setuids (!)
- ... uses dbus to send notification, it really actually works awesomely AND is with tiny adjustments usable also by KDE/XFCE etc
- ... dies.

It is simple, passive, working. Comments from some real developers?

Revision history for this message
trollord (trollenlord) wrote :

I took a look also at /etc/default/smartmontools. One could pass there -d ata for my devices, but the smartd.conf's DEVICESCAN line breaks that.

Getting something like smartd automatically actually working for most of the people will require some work.

Revision history for this message
trollord (trollenlord) wrote :

This is what it looks like :-)

Revision history for this message
sam tygier (samtygier) wrote :

karmic has disk monitoring and testing tools that match most of this description. i suggest any additional features are filed individually against Palimpsest

Changed in smartmontools (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.