I propose an usability improvement: Notify the user by default, in addition to sending an email to root. It's true that fedora can be used in servers, so it's useful to send an email to root by default when a disk is starting to fail. But it's also true that fedora is used in desktops, where the user rarely logins as root to see the root mail, so it's also useful to notify the user by default. Both things can be trivially done by adding some options to smartd.conf, and by creating a script file to process the actions to be done. This is the current default /etc/smartd.conf file installed by fedora: DEVICESCAN -H -m root -n standby,10,q And this is the new /etc/smartd.conf file to implement the proposal: DEVICESCAN -H -m root -M exec /usr/lib/smartd_actions -n standby,10,q So, to process the actions to be done when a disk begins to fail, the "/usr/lib/smartd_actions" file is launched. In order to send an email to root, and to notify the desktop user, the content of "/usr/lib/smartd_actions" can be: -------------- #! /bin/sh # Send mail echo "$SMARTD_MESSAGE" | mail -s "$SMARTD_FAILTYPE" "$SMARTD_ADDRESS" # Notify desktop user /usr/bin/notify-send -t 0 "WARNING: Your hard disk drive is failing!" "Description: $SMARTD_MESSAGE" -------------- To test the proposal, just add "-M test" option to the smartd.conf line, in this way: DEVICESCAN -H -m root -M test -M exec /usr/lib/smartd_actions -n standby,10,q and restart the smartd daemon ("/etc/init.d/smartd restart" command). With the proposal, both server users and desktop users will be happy, with zero effort. I'm curretly running the proposal (well, I've commented out the root mail command at smartd_actions script), and it works fine. I needed many hours to understand how smartd works and its options, and to find a way to notify the user with the available smartd options. By including the proposal into fedora by default, users will need zero hours to have the thing working. Thanks
well... this is quite interesting idea, I'll look at it.
smartmontools-5.40-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/smartmontools-5.40-6.fc15
smartmontools-5.40-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/smartmontools-5.40-4.fc14
smartmontools-5.40-6.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update smartmontools'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/smartmontools-5.40-6.fc15
Will this not duplicate functionality found in gnome-disk-utility on the default GNOME-desktop? I remember getting messages in notification area from gdu when logging in with failing disks, but currently I have none easily connected to test with.
the answer is "maybe", but gnome-disk-utility is not used in all desktop environments and also smartd is not installed and running by default, so I don't see any problem here.
smartmontools-5.40-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
smartmontools-5.40-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
A small bug prevents this great usability enhancement from working. The notify script in the package is installed to "/usr/libexec/smartmontools/smartdnotify" but /etc/smartd.conf points at the non-existent "/usr/lib/smartd_actions" proposed script. So, /etc/smartd.conf just needs a small fix to point at the actual script for this to work outofthebox.
I see 2 issues: 1. /usr/bin/notify-send requires DISPLAY and XAUTHORITY environment variables and when started at system boot these are not available - so the notifications are not displayed (when the service is restarted from within gnome-terminal, the variables are inherited from it) 2. /usr/libexec/smartmontools/smartdnotify script is not i18n friendly - so the message (when it finally displays, after solving the 1. part) is only in english language
(In reply to comment #10) > 1. /usr/bin/notify-send requires DISPLAY and XAUTHORITY environment variables The first problem can at least be worked around by sleeping for a few minutes, giving enough time gdm to start and a user to log in, and then setting the needed env variables ourselves using a "hack", such as: export DISPLAY=:0; export XAUTHORITY=$(ls -td /var/run/gdm/auth*gdm*|head -1)/database; /usr/bin/notify-send -u critical -t 0 'WARNING: Foo!'
I knew its going to be complicated :) Maybe wall is better for this than notify-send? Solution from comment #11 works only for gdm, does not work for kdm, so more code is needed (and it'll little bit be more ugly) My present idea is: 1. smartdnotify is called 2. try to get XAUTHORITY and DISPLAY variables 3. if X session is not running, wait (two minutes?) 4. try again to get both variables 5. on success use notify-send 6. on failure use wall any different ideas? comments?
That's true, notifications won't be shown because the smartd daemon is started before X, and "notify-send" requires the X session info ($DISPLAY and company) to work. "wall" command doesn't require the X session info, and the notifications will be shown to desktop users too, so probably it's the way to go. Just use the following command at "/usr/libexec/smartmontools/smartdnotify" file: -------------- # Notify desktop user /usr/bin/wall -n "WARNING: Your hard drive is failing. Description: $SMARTD_MESSAGE" -------------- That solves the X session info problem. I only see 3 minor problems: 1. We loose the spetific title at desktop notification ("wall" command only accepts a description). 2. The notification will also appear at text consoles (control+alt+Fx) and at gnome/kde consoles. (maybe an adventage instead of a problem?) 3. If the user is not logged in (gdm/kdm is shown), the notification is lost (it is not saved, to be shown when the user logs in). (it probably also happens with "notify-send") The first two problems seems to be very minor to me. The third problem looks like a pending point in the linux notification system: When no users are logged in, notifications should be stored, in order to be shown when the users log in. Currently, those notifications are lost. I've searched at the internet, but I haven't found any command/way to do it. I'll write a suggestion (to some notification component) to add the notification save/recover idea. In the mean time, I think the "wall" command is the way to go for smartd. Thanks
(In reply to comment #9) > A small bug prevents this great usability enhancement from working. The notify > script in the package is installed to "/usr/libexec/smartmontools/smartdnotify" > but /etc/smartd.conf points at the non-existent "/usr/lib/smartd_actions" > proposed script. > > So, /etc/smartd.conf just needs a small fix to point at the actual script for > this to work outofthebox. Yeah, I just ran across this bug when I noticed that 1) my /etc/smartd.conf was wiped out when I updated this package at some point, and 2) the smartd_actions file mentioned above didn't exist, so I didn't get any notification at all. Will this be fixed? I have updated my config but the only reason I noticed was when I had 10 pages of errors in my logwatch.
smartd.conf is fixed smartdnotify uses something like "wall" just without wall's ugly header
smartmontools-5.40-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/smartmontools-5.40-6.fc14
smartmontools-5.40-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/smartmontools-5.40-9.fc15
Package smartmontools-5.40-6.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing smartmontools-5.40-6.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/smartmontools-5.40-6.fc14 then log in and leave karma (feedback).
smartmontools-5.40-9.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
smartmontools-5.40-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.