Package: mdadm
Version: 4.0-2
Severity: normal
Tags: patch
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

While using RAID5 array in an automated test I encountered a situation where
an active array was successfully mounted during boot, but shortly later the
device was unmounted leaving a log message like:

mdadm-last-resort@md0.service starting,
Unmounting /mnt/iscsi1

Which indicated that this service was running and responsible for unmounting
the RAID array.  

Looking upstream, there has been a change to the mdadm-last-resort service
to ensure that it does not run on active arrays.

In Ubuntu, the attached patch was applied to achieve the following:

  * Ensure mdadm-last-resort services only runs when it is needed LP: #1753786

Thanks for considering the patch.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-36-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru mdadm-4.0/debian/patches/mdadm-last-resort-use-condition-path-exists.patch mdadm-4.0/debian/patches/mdadm-last-resort-use-condition-path-exists.patch
--- mdadm-4.0/debian/patches/mdadm-last-resort-use-condition-path-exists.patch	1969-12-31 18:00:00.000000000 -0600
+++ mdadm-4.0/debian/patches/mdadm-last-resort-use-condition-path-exists.patch	2018-03-07 02:34:12.000000000 -0600
@@ -0,0 +1,46 @@
+From 5c4b3b9aa9f576305b36d5ccbd4b929b51307ce9 Mon Sep 17 00:00:00 2001
+From: NeilBrown <>
+Date: Thu, 20 Apr 2017 12:40:05 +1000
+Subject: [PATCH] systemd/mdadm-last-resort: use ConditionPathExists instead of
+ Conflicts
+Commit cec72c071bbe ("systemd/mdadm-last-resort: add Conflicts to .service file.")
+added a 'Conflicts' directive to the mdadm-last-resort@.service file in
+the hope that this would make sure the service didn't run after the device
+was active, even if the timer managed to get started, which is possible in
+race conditions.
+This seemed to work is testing, but it isn't clear why, and it is known
+to cause problems.
+If systemd happens to know that the mentioned device is a dependency of a
+mount point, the Conflicts can unmount that mountpoint, which is certainly
+not wanted.
+So remove the "Conflicts" and instead use
+ ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action
+The "sync_action" file exists for any array which requires last-resort
+handling, and only appears when the array is activated.  So it is safe
+to rely on it to determine if the last-resort is really needed.
+Fixes: cec72c071bbe ("systemd/mdadm-last-resort: add Conflicts to .service file.")
+Signed-off-by: NeilBrown <>
+Signed-off-by: Jes Sorensen <>
+ systemd/mdadm-last-resort@.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+diff --git a/systemd/mdadm-last-resort@.service b/systemd/mdadm-last-resort@.service
+index e93d72b2..f9d4d127 100644
+--- a/systemd/mdadm-last-resort@.service
++++ b/systemd/mdadm-last-resort@.service
+@@ -1,7 +1,7 @@
+ [Unit]
+ Description=Activate md array even though degraded
+ DefaultDependencies=no
+ [Service]
+ Type=oneshot
diff -Nru mdadm-4.0/debian/patches/series mdadm-4.0/debian/patches/series
--- mdadm-4.0/debian/patches/series	2017-05-12 06:28:13.000000000 -0500
+++ mdadm-4.0/debian/patches/series	2018-03-07 02:34:12.000000000 -0600
@@ -3,3 +3,4 @@

Reply via email to