Bug 640148
| Summary: | mdadm --monitor does not | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Levon <levon> |
| Component: | mdadm | Assignee: | Doug Ledford <dledford> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | dledford |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-23 19:29:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The MAILADDR line is commented out, and there is no PROGRAM line, so mdmonitor will not start. You will need to uncomment the MAILADDR line in order for the service to work. To quote mdadm's man page: "Without --scan, mdadm will continue monitoring as long as something was found to monitor. If no program or email is given, then each event is reported to stdout." Ah, I see. You are running it from the command line to monitor output. However, your own comments don't indicate if anything of interest occured (such as the array transitioning from active to degraded state). The event count is not enough to know whether or not mdadm --monitor should output anything (in other words, when the man page says it reports each event, that's each event from the list of event types mdadm monitor cares about, not necessarily events that trigger an update to the event counter). There are a list of events that monitor mode watches for, and it emits a message only on those events. In addition, it emits messages on *transitions* from one state to another. So, if an array is already degraded, then a new event that didn't transition the array from active to degraded will not trigger a degraded email. In order to test and see if things are truly awry, you would need to start mdadm in monitor mode, and then transition an array from a good state to a degraded state, and in that case you should get an output on stdout. Closing this back out, reopen if mdadm doesn't perform in the regard I mentioned. |
# cat /etc/mdadm.conf # mdadm.conf written out by anaconda #MAILADDR root AUTO +imsm +1.x -all ARRAY /dev/md0 level=raid1 num-devices=2 UUID=3d6a48f2:d201f442:d6582c26:de55b491 ARRAY /dev/md1 level=raid1 num-devices=2 UUID=3ca40f3a:5cac2743:ae9a0e8b:f01c2cc2 [root@pent etc]# mdadm --monitor /dev/md0 <nothing appears> but: # mdadm --detail --verbose /dev/md1 | grep Events ; sleep 10 ; mdadm --detail --verbose /dev/md1 | grep Events Events : 10283 Events : 10287 [root@pent ~]# rpm -q mdadm mdadm-3.1.2-10.fc13.x86_64 [root@pent ~]# rpm -q kernel kernel-2.6.33.3-85.fc13.x86_64 kernel-2.6.34.7-56.fc13.x86_64