Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#48331 - [mdadm] mdmonitor.service not started when using mdadm_udev initcpio hook on RAID-1 root

Attached to Project: Arch Linux
Opened by Jonathan Liu (net147) - Thursday, 25 February 2016, 04:19 GMT
Last edited by Toolybird (Toolybird) - Sunday, 11 June 2023, 04:18 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No


Normally the udev rules in the mdadm package are supposed to trigger the start of mdmonitor.service but this doesn't seem to work when a RAID-1 root is assembled in the initcpio. Probably because there isn't a systemd environment, mdmonitor.service and related dependencies in the initcpio...

Perhaps we should add an Install section to mdmonitor.service so that it can be explicitly enabled and started on boot in this case?

Additional info:
* mdadm 3.3.4-1

Steps to reproduce:
1. Install Arch Linux on mdadm RAID-1 and configure mdadm.conf for mail notifications as described in
2. Reboot
3. systemctl status mdmonitor.service
This task depends upon

Closed by  Toolybird (Toolybird)
Sunday, 11 June 2023, 04:18 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Config error. See comments.
Comment by Jonathan Liu (net147) - Thursday, 25 February 2016, 04:32 GMT
Solution is to add the following to mdmonitor.service:

Then the mdmonitor.service can be explicitly enabled:
systemctl enable mdmonitor.service
systemctl start mdmonitor.service

It would be bad if a RAID array failed without getting a notification because of this bug...
Comment by David Scholberg (therealarchdaemon) - Sunday, 28 February 2016, 15:44 GMT
I'm affected by this.

What makes this even worse is that if you try to enable mdmonitor.service as is, then systemctl will silently fail to create the symlink instead of giving an error about not being able to enable the service, which gives the user a false sense of security. The lack of error message is, of course, a systemd problem, but it's still worth noting.
Comment by Bogdan Szczurek (thebodzio) - Tuesday, 26 June 2018, 23:36 GMT
I'd love to add something more constructive to this discussion, but I'm afraid the only thing I can do is to confirm the bug :{

The only thing that appeared to changed is systemctl reaction, which as of June 2018 provides very explicit warning about not being able to enable mdmonitor.service. Right now I'm using Jonathan's workaround to start the monitoring service, but I hope for more “default” solution.
Comment by Eli Schwartz (eschwartz) - Friday, 27 July 2018, 15:44 GMT
The mdmonitor.service file comes from upstream, so please discuss this with the upstream mdadm developers:
Comment by Toolybird (Toolybird) - Sunday, 11 June 2023, 04:18 GMT
This is covered in the Wiki [1]. Failing to configure it properly results in error.