mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send

Bug #535417 reported by ceg on 2010-03-09
60
This bug affects 10 people
Affects Status Importance Assigned to Milestone
mdadm (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: mdadm

Anybody who cares enough about redundancy to use mdadm probably cares enough to want getting informed if redundancy is degraded.

Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install.

By default ubuntu systems do not support local mail, and the mdadm package was patched to suppress the installation of an MTA/MDA (only if installed during the initial installation Bug #379882 ), without adapting mdadm --monitor to use "wall" or "notify-send" as a replacement.

As informing a human is a serious data protection topic, mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out.

---

The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid.

So you can replace disks etc. ahead of a total failure.

To send out notifications mdadm needs a sendmail command (MTA mail transport agent ).

To deliver mail localy you need a mail delivery agent (MDA)

Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery.

If no MTA/MDA is installed, yes mdadm should pull in (require) one.
However, maybe a small replacement like esmtp + procmail (if they are
supported) instead of postfix on desktops.

---

Workaround to manually set up local delivery for email send to "root":

 #apt-get install postfix procmail
 # (choose to configure for local use only)
 #echo "root: <YOUR-USER-NAME-HERE>" >> /etc/aliases
 #newaliases
 #mdadm --monitor /dev/md0 --test
 #^C

Then set up an mail program to check for email in your local mailbox
(/var/mail/<YOUR-USER-NAME-HERE>).

ceg (ceg) on 2010-03-09
summary: - mdadm monitor feature is disabled, not depending on local MTA/MDA or
+ mdadm monitor feature broken, not depending on local MTA/MDA or using
wall/notify-send
description: updated
tags: added: kernel-series-unknown
tags: removed: kernel-series-unknown

manual workaround: install esmtp and procmail (and configure procmail as local delivery agent, see /usr/share/doc/esmtp)

ceg (ceg) on 2010-03-24
Changed in mdadm (Ubuntu):
status: New → Confirmed
ceg (ceg) wrote :

explicit workaround commands using esmtp:

#apt-get install esmtp procmail
#echo mda=\'/usr/bin/formail -a \"Date: \`date -R\`\" \| /usr/bin/procmail -d %T\'

ceg (ceg) wrote :

last line needs to address for esmtprc of course:

#echo mda=\'/usr/bin/formail -a \"Date: \`date -R\`\" \| /usr/bin/procmail -d %T\' >> /etc/esmtprc

ceg (ceg) on 2010-03-29
description: updated
ceg (ceg) on 2010-03-29
description: updated
ceg (ceg) wrote :

On the other hand mdadm "recommends" postfix | mail-transport-agent.

So a synaptic install (not the initial install) seems to pull in postfix on Desktops!

Bug #379882

ceg (ceg) on 2010-04-14
summary: - mdadm monitor feature broken, not depending on local MTA/MDA or using
- wall/notify-send
+ mdadm monitor feature broken, not depending on local MTA/MDA nor using
+ beep/wall/notify-send
description: updated
ceg (ceg) on 2010-04-26
summary: - mdadm monitor feature broken, not depending on local MTA/MDA nor using
+ mdadm monitor feature broken, email notification not set up, nor using
beep/wall/notify-send
description: updated
stenzn (stenzn) wrote :

I've been trying to get something usable at least using notify-send as an external program to trigger, but I'm having trouble getting it to execute on failure, and I got sick of unplugging a hard drive and then waiting for the entire array to rebuild. If I can figure out how to get it working, maybe I could come up with a new default mdadm config file with external program notification.

However, that runs into another bug- Ubuntu's default notifier applet ignores the timeout parameter from notify-send, so there's no way to ensure the message stays on the screen for a while without popping up a dialog box with an OK button or something. I like a notification bubble better than a dialog box, but I think obviously the user should have to click that the message was read... which is no longer an option- Ubuntu notification bubbles aren't allowed to have buttons, nor can you specify the amount of time they're displayed for (this regression has been declared as by design).

Sooo something other than notify-send will probably be necessary. I just don't know what other options there are.

I don't like the local mail option since Ubuntu doesn't normally even have the concept of it. All of my mail is webmail, so I wouldn't want a mail client running just to see if I have a drive failure- doesn't make much sense to me.

ceg (ceg) wrote :

> I got sick of unplugging a hard drive and then waiting for the entire array to rebuild.

Maybe try mdadm's --monitor --test option to generate test messages.

(Or have your arrays --grow a bitmaps to speed up resync.)

Cerin (chrisspen) wrote :

An email is essential, but something like the red crash report icon in the notification area would be very useful. If Openoffice crashing warrants a notification area icon, then my entire RAID array failing surely warrants something as well.

alfonso (alfonso-fiore) wrote :

Hello,

this bug is confirmed, but I don't see anywhere that has been fixed.

My apologies if I don't know how to read launchpad. :(

Does it mean it is still existing 18 months after?

thank you!

ceg (ceg) on 2012-11-28
description: updated
description: updated
ceg (ceg) on 2012-11-28
description: updated
ceg (ceg) on 2012-11-28
description: updated
description: updated
ceg (ceg) on 2012-11-28
description: updated
ceg (ceg) on 2012-11-28
description: updated
ceg (ceg) on 2012-12-11
description: updated
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers