[PATCH 1/2] mkdumprd: don't add "x-initrd.mount" if nfs mounted to the save path

[Xunlei Pang]

I found this problem when debugging "Transaction is destructive"
(see the following patch) issue using nfs, in the case that nfs
is mounted implicitly to the save path other than explicitly
using the "nfs" directive in /etc/kdump.conf, "is_nfs_dump_target"
will return false, so this nfs mount will be added "x-initrd.mount"
option wrongly.

It affects the systemd service behaviours when emergency failure
happens as the code comment described.

To fix it, we use "is_fs_type_nfs $_fstype" instead.

Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
---
 mkdumprd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mkdumprd b/mkdumprd
index f30d9c2..f1bac01 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -120,7 +120,7 @@ to_mount() {
     # If remote mount fails, dracut-initqueue will still start and once
     # dracut-initqueue finishes, kdump service will start. Because remote mount
     # failed, kdump service will fail and it will lead to kdump error handler.
-    if ! is_nfs_dump_target; then
+    if ! is_fs_type_nfs $_fstype; then
        _options="$_options,x-initrd.mount"
     fi
     _mntopts="$_target $_fstype $_options"
-- 
1.8.3.1

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

We met a problem that the kdump emergency service failed to
start when the target dump timeout(we passed "rd.timeout=30"
to kdump), it reported "Transaction is destructive" messages:

  [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
  [DEPEND] Dependency failed for Initrd Root Device.
  [ SKIP ] Ordering cycle found, skipping System Initialization
  [DEPEND] Dependency failed for /sysroot.
  [DEPEND] Dependency failed for Initrd Root File System.
  [DEPEND] Dependency failed for Reload Configuration from the Real Root.
  [ SKIP ] Ordering cycle found, skipping System Initialization
  [ SKIP ] Ordering cycle found, skipping Initrd Default Target
  [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
  [  OK  ] Reached target Initrd File Systems.
  [  OK  ] Stopped dracut pre-udev hook.
  [  OK  ] Stopped dracut cmdline hook.
           Starting Setup Virtual Console...
           Starting Kdump Emergency...
  [  OK  ] Reached target Initrd Default Target.
  [  OK  ] Stopped dracut initqueue hook.
  Failed to start kdump-error-handler.service: Transaction is destructive.
  See system logs and 'systemctl status kdump-error-handler.service' for details.
  [FAILED] Failed to start Kdump Emergency.
  See 'systemctl status emergency.service' for details.
  [DEPEND] Dependency failed for Emergency Mode.

This is because in case of root failure, initrd-root-fs.target
will trigger systemd emergency target which requires the systemd
emergency service actually is kdump-emergency.service, then our
kdump-emergency.service starts kdump-error-handler.service with
"systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
replace systemd's with this one under kdump).

This will lead to systemd two contradictable jobs queued as an
atomic transaction:
job 1) the emergency service gets started by initrd-root-fs.target
job 2) the emergency service gets stopped due to "systemctl isolate"
thereby throwing "Transaction is destructive".

In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
both kdump-emergency.service and kdump-emergency.target to avoid
being isolated, then they can keep going on as expected in case
of failures.

We add kdump-emergency.target dedicated to kdump the similar way
as did for kdump-emergency.service(i.e. will replace systemd's
emergency.target with kdump-emergency.target under kdump), and
adds "IgnoreOnIsolate=yes" into both of them.

Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
---
 dracut-kdump-emergency.service |  1 +
 dracut-kdump-emergency.target  | 14 ++++++++++++++
 dracut-module-setup.sh         |  3 ++-
 kexec-tools.spec               |  2 ++
 4 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 dracut-kdump-emergency.target

diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
index fb764f2..e023284 100644
--- a/dracut-kdump-emergency.service
+++ b/dracut-kdump-emergency.service
@@ -12,6 +12,7 @@
 [Unit]
 Description=Kdump Emergency
 DefaultDependencies=no
+IgnoreOnIsolate=yes
 
 [Service]
 ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
new file mode 100644
index 0000000..a1bb493
--- /dev/null
+++ b/dracut-kdump-emergency.target
@@ -0,0 +1,14 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+[Unit]
+Description=Emergency Mode
+Documentation=man:systemd.special(7)
+Requires=emergency.service
+After=emergency.service
+AllowIsolate=yes
+IgnoreOnIsolate=yes
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 1f96bb8..fa4fa2a 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -734,8 +734,9 @@ install() {
     ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
     inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
     inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
-    # Replace existing emergency service
+    # Replace existing emergency service and emergency target
     cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
+    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
     # Also redirect dracut-emergency to kdump error handler
     ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
 
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 2a176f3..c3359fb 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
 Source104: dracut-kdump-emergency.service
 Source105: dracut-kdump-error-handler.service
 Source106: dracut-kdump-capture.service
+Source107: dracut-kdump-emergency.target
 
 Requires(post): systemd-units
 Requires(preun): systemd-units
@@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
 cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
 cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
 cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
+cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
 chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
 chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
 
-- 
1.8.3.1

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Pratyush Anand]

Hi Xunlei,

On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
>  We met a problem that the kdump emergency service failed to
>  start when the target dump timeout(we passed "rd.timeout=30"
>  to kdump), it reported "Transaction is destructive" messages:
>
>    [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
>    [DEPEND] Dependency failed for Initrd Root Device.
>    [ SKIP ] Ordering cycle found, skipping System Initialization
>    [DEPEND] Dependency failed for /sysroot.
>    [DEPEND] Dependency failed for Initrd Root File System.
>    [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>    [ SKIP ] Ordering cycle found, skipping System Initialization
>    [ SKIP ] Ordering cycle found, skipping Initrd Default Target
>    [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
>    [  OK  ] Reached target Initrd File Systems.
>    [  OK  ] Stopped dracut pre-udev hook.
>    [  OK  ] Stopped dracut cmdline hook.
>             Starting Setup Virtual Console...
>             Starting Kdump Emergency...
>    [  OK  ] Reached target Initrd Default Target.
>    [  OK  ] Stopped dracut initqueue hook.
>    Failed to start kdump-error-handler.service: Transaction is destructive.
>    See system logs and 'systemctl status kdump-error-handler.service' for
> details.
>    [FAILED] Failed to start Kdump Emergency.
>    See 'systemctl status emergency.service' for details.
>    [DEPEND] Dependency failed for Emergency Mode.
>
>  This is because in case of root failure, initrd-root-fs.target
>  will trigger systemd emergency target which requires the systemd
>  emergency service actually is kdump-emergency.service, then our
>  kdump-emergency.service starts kdump-error-handler.service with
>  "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
>  replace systemd's with this one under kdump). 
I could not understand why kdump emergency.service needs isolate while, 
it is not needed in first kernel (ie in systemd). If kdump would work 
without isolate then probably it will be more closer to upstream systemd 
and we will need less modifications in kdump.

~Pratyush
>
> This will lead to systemd two contradictable jobs queued as an
> atomic transaction:
> job 1) the emergency service gets started by initrd-root-fs.target
> job 2) the emergency service gets stopped due to "systemctl isolate"
> thereby throwing "Transaction is destructive".
>
> In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> both kdump-emergency.service and kdump-emergency.target to avoid
> being isolated, then they can keep going on as expected in case
> of failures.
>
> We add kdump-emergency.target dedicated to kdump the similar way
> as did for kdump-emergency.service(i.e. will replace systemd's
> emergency.target with kdump-emergency.target under kdump), and
> adds "IgnoreOnIsolate=yes" into both of them.
>
> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> ---
>  dracut-kdump-emergency.service |  1 +
>  dracut-kdump-emergency.target  | 14 ++++++++++++++
>  dracut-module-setup.sh         |  3 ++-
>  kexec-tools.spec               |  2 ++
>  4 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 dracut-kdump-emergency.target
>
> diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
> index fb764f2..e023284 100644
> --- a/dracut-kdump-emergency.service
> +++ b/dracut-kdump-emergency.service
> @@ -12,6 +12,7 @@
>  [Unit]
>  Description=Kdump Emergency
>  DefaultDependencies=no
> +IgnoreOnIsolate=yes
>
>  [Service]
>  ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
> diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> new file mode 100644
> index 0000000..a1bb493
> --- /dev/null
> +++ b/dracut-kdump-emergency.target
> @@ -0,0 +1,14 @@
> +#  This file is part of systemd.
> +#
> +#  systemd is free software; you can redistribute it and/or modify it
> +#  under the terms of the GNU Lesser General Public License as published by
> +#  the Free Software Foundation; either version 2.1 of the License, or
> +#  (at your option) any later version.
> +
> +[Unit]
> +Description=Emergency Mode
> +Documentation=man:systemd.special(7)
> +Requires=emergency.service
> +After=emergency.service
> +AllowIsolate=yes
> +IgnoreOnIsolate=yes
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index 1f96bb8..fa4fa2a 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -734,8 +734,9 @@ install() {
>      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
>      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
>      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> -    # Replace existing emergency service
> +    # Replace existing emergency service and emergency target
>      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
>      # Also redirect dracut-emergency to kdump error handler
>      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
>
> diff --git a/kexec-tools.spec b/kexec-tools.spec
> index 2a176f3..c3359fb 100644
> --- a/kexec-tools.spec
> +++ b/kexec-tools.spec
> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
>  Source104: dracut-kdump-emergency.service
>  Source105: dracut-kdump-error-handler.service
>  Source106: dracut-kdump-capture.service
> +Source107: dracut-kdump-emergency.target
>
>  Requires(post): systemd-units
>  Requires(preun): systemd-units
> @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
>  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
>  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
>  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
>
>

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
>  Hi Xunlei,
>
>  On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
> > We met a problem that the kdump emergency service failed to
> > start when the target dump timeout(we passed "rd.timeout=30"
> > to kdump), it reported "Transaction is destructive" messages:
> >
> >   [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
> >   [DEPEND] Dependency failed for Initrd Root Device.
> >   [ SKIP ] Ordering cycle found, skipping System Initialization
> >   [DEPEND] Dependency failed for /sysroot.
> >   [DEPEND] Dependency failed for Initrd Root File System.
> >   [DEPEND] Dependency failed for Reload Configuration from the Real Root.
> >   [ SKIP ] Ordering cycle found, skipping System Initialization
> >   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
> >   [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
> >   [  OK  ] Reached target Initrd File Systems.
> >   [  OK  ] Stopped dracut pre-udev hook.
> >   [  OK  ] Stopped dracut cmdline hook.
> >            Starting Setup Virtual Console...
> >            Starting Kdump Emergency...
> >   [  OK  ] Reached target Initrd Default Target.
> >   [  OK  ] Stopped dracut initqueue hook.
> >   Failed to start kdump-error-handler.service: Transaction is destructive.
> >   See system logs and 'systemctl status kdump-error-handler.service' for
> details.
> >   [FAILED] Failed to start Kdump Emergency.
> >   See 'systemctl status emergency.service' for details.
> >   [DEPEND] Dependency failed for Emergency Mode.
> >
> > This is because in case of root failure, initrd-root-fs.target
> > will trigger systemd emergency target which requires the systemd
> > emergency service actually is kdump-emergency.service, then our
> > kdump-emergency.service starts kdump-error-handler.service with
> > "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
> > replace systemd's with this one under kdump).
>
>  I could not understand why kdump emergency.service needs isolate while, it is not needed
> in first kernel (ie in systemd). If kdump would work without isolate then probably it will
> be more closer to upstream systemd and we will need less modifications in kdump. 
Yes, what you said is another solution.

Seems Dave has some concern about we may not stop some services like before if replacing
"isolate" with "start".
From my tests it is true that some services will be continuing.

Hi Dave, what is you opinion?

Regards,
Xunlei

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Dave Young]

On 03/27/17 at 04:03pm, Xunlei Pang wrote:
>  On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
>  > Hi Xunlei,
>  >
>  > On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
>  >> We met a problem that the kdump emergency service failed to
>  >> start when the target dump timeout(we passed "rd.timeout=30"
>  >> to kdump), it reported "Transaction is destructive" messages:
>  >>
>  >>   [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
>  >>   [DEPEND] Dependency failed for Initrd Root Device.
>  >>   [ SKIP ] Ordering cycle found, skipping System Initialization
>  >>   [DEPEND] Dependency failed for /sysroot.
>  >>   [DEPEND] Dependency failed for Initrd Root File System.
>  >>   [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>  >>   [ SKIP ] Ordering cycle found, skipping System Initialization
>  >>   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
>  >>   [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
>  >>   [  OK  ] Reached target Initrd File Systems.
>  >>   [  OK  ] Stopped dracut pre-udev hook.
>  >>   [  OK  ] Stopped dracut cmdline hook.
>  >>            Starting Setup Virtual Console...
>  >>            Starting Kdump Emergency...
>  >>   [  OK  ] Reached target Initrd Default Target.
>  >>   [  OK  ] Stopped dracut initqueue hook.
>  >>   Failed to start kdump-error-handler.service: Transaction is destructive.
>  >>   See system logs and 'systemctl status kdump-error-handler.service' for
> details.
>  >>   [FAILED] Failed to start Kdump Emergency.
>  >>   See 'systemctl status emergency.service' for details.
>  >>   [DEPEND] Dependency failed for Emergency Mode.
>  >>
>  >> This is because in case of root failure, initrd-root-fs.target
>  >> will trigger systemd emergency target which requires the systemd
>  >> emergency service actually is kdump-emergency.service, then our
>  >> kdump-emergency.service starts kdump-error-handler.service with
>  >> "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
>  >> replace systemd's with this one under kdump).
>  >
>  > I could not understand why kdump emergency.service needs isolate while, it is not
> needed in first kernel (ie in systemd). If kdump would work without isolate then probably
> it will be more closer to upstream systemd and we will need less modifications in kdump.
>  
>  Yes, what you said is another solution.
>  
>  Seems Dave has some concern about we may not stop some services like before if replacing
> "isolate" with "start".
>  From my tests it is true that some services will be continuing.
>  
>  Hi Dave, what is you opinion? 
I do not remember why we use isolate previously. I thought it is for
force run kdump error handler service so that kdump error handler ensure
not to be blocked by other services.

Suppose other service can run in an infinite loop, does the "start"
still work for us? For example we expect "default shell" but other
services runs in a loop or something else..

Thanks
Dave

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/27/2017 at 04:25 PM, Dave Young wrote:
>  On 03/27/17 at 04:03pm, Xunlei Pang wrote:
> > On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
> >> Hi Xunlei,
> >>
> >> On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
> >>> We met a problem that the kdump emergency service failed to
> >>> start when the target dump timeout(we passed "rd.timeout=30"
> >>> to kdump), it reported "Transaction is destructive" messages:
> >>>
> >>>   [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
> >>>   [DEPEND] Dependency failed for Initrd Root Device.
> >>>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>>   [DEPEND] Dependency failed for /sysroot.
> >>>   [DEPEND] Dependency failed for Initrd Root File System.
> >>>   [DEPEND] Dependency failed for Reload Configuration from the Real Root.
> >>>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>>   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
> >>>   [DEPEND] Dependency failed for File System Check on
> /dev/mapper/fedora-root.
> >>>   [  OK  ] Reached target Initrd File Systems.
> >>>   [  OK  ] Stopped dracut pre-udev hook.
> >>>   [  OK  ] Stopped dracut cmdline hook.
> >>>            Starting Setup Virtual Console...
> >>>            Starting Kdump Emergency...
> >>>   [  OK  ] Reached target Initrd Default Target.
> >>>   [  OK  ] Stopped dracut initqueue hook.
> >>>   Failed to start kdump-error-handler.service: Transaction is destructive.
> >>>   See system logs and 'systemctl status kdump-error-handler.service'
> for details.
> >>>   [FAILED] Failed to start Kdump Emergency.
> >>>   See 'systemctl status emergency.service' for details.
> >>>   [DEPEND] Dependency failed for Emergency Mode.
> >>>
> >>> This is because in case of root failure, initrd-root-fs.target
> >>> will trigger systemd emergency target which requires the systemd
> >>> emergency service actually is kdump-emergency.service, then our
> >>> kdump-emergency.service starts kdump-error-handler.service with
> >>> "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
> >>> replace systemd's with this one under kdump).
> >> I could not understand why kdump emergency.service needs isolate while, it is not
> needed in first kernel (ie in systemd). If kdump would work without isolate then probably
> it will be more closer to upstream systemd and we will need less modifications in kdump.
> > Yes, what you said is another solution.
> >
> > Seems Dave has some concern about we may not stop some services like before if
> replacing "isolate" with "start".
> > From my tests it is true that some services will be continuing.
> >
> > Hi Dave, what is you opinion?
>  I do not remember why we use isolate previously. I thought it is for
>  force run kdump error handler service so that kdump error handler ensure
>  not to be blocked by other services.
>
>  Suppose other service can run in an infinite loop, does the "start"
>  still work for us? For example we expect "default shell" but other
>  services runs in a loop or something else..
>  
It may be due to our "default XXX" feature, we have to ensure it executes
reliably as possible as it can in case of emergency.
In my view, we have been using "isolate" since 2014, better no touch that,
that's why after some thinking I choose this method.

Regards,
Xunlei

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/27/2017 at 04:38 PM, Xunlei Pang wrote:
>  On 03/27/2017 at 04:25 PM, Dave Young wrote:
> > On 03/27/17 at 04:03pm, Xunlei Pang wrote:
> >> On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
> >>> Hi Xunlei,
> >>>
> >>> On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
> >>>> We met a problem that the kdump emergency service failed to
> >>>> start when the target dump timeout(we passed "rd.timeout=30"
> >>>> to kdump), it reported "Transaction is destructive" messages:
> >>>>
> >>>>   [ TIME ] Timed out waiting for device
> dev-mapper-fedora\x2droot.device.
> >>>>   [DEPEND] Dependency failed for Initrd Root Device.
> >>>>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>>>   [DEPEND] Dependency failed for /sysroot.
> >>>>   [DEPEND] Dependency failed for Initrd Root File System.
> >>>>   [DEPEND] Dependency failed for Reload Configuration from the Real
> Root.
> >>>>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>>>   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
> >>>>   [DEPEND] Dependency failed for File System Check on
> /dev/mapper/fedora-root.
> >>>>   [  OK  ] Reached target Initrd File Systems.
> >>>>   [  OK  ] Stopped dracut pre-udev hook.
> >>>>   [  OK  ] Stopped dracut cmdline hook.
> >>>>            Starting Setup Virtual Console...
> >>>>            Starting Kdump Emergency...
> >>>>   [  OK  ] Reached target Initrd Default Target.
> >>>>   [  OK  ] Stopped dracut initqueue hook.
> >>>>   Failed to start kdump-error-handler.service: Transaction is
> destructive.
> >>>>   See system logs and 'systemctl status
> kdump-error-handler.service' for details.
> >>>>   [FAILED] Failed to start Kdump Emergency.
> >>>>   See 'systemctl status emergency.service' for details.
> >>>>   [DEPEND] Dependency failed for Emergency Mode.
> >>>>
> >>>> This is because in case of root failure, initrd-root-fs.target
> >>>> will trigger systemd emergency target which requires the systemd
> >>>> emergency service actually is kdump-emergency.service, then our
> >>>> kdump-emergency.service starts kdump-error-handler.service with
> >>>> "systemctl isolate"(see 99kdumpbase/kdump-emergency.service,
> we
> >>>> replace systemd's with this one under kdump).
> >>> I could not understand why kdump emergency.service needs isolate while, it is
> not needed in first kernel (ie in systemd). If kdump would work without isolate then
> probably it will be more closer to upstream systemd and we will need less modifications in
> kdump.
> >> Yes, what you said is another solution.
> >>
> >> Seems Dave has some concern about we may not stop some services like before if
> replacing "isolate" with "start".
> >> From my tests it is true that some services will be continuing.
> >>
> >> Hi Dave, what is you opinion?
> > I do not remember why we use isolate previously. I thought it is for
> > force run kdump error handler service so that kdump error handler ensure
> > not to be blocked by other services.
> >
> > Suppose other service can run in an infinite loop, does the "start"
> > still work for us? For example we expect "default shell" but other
> > services runs in a loop or something else..
> >
>  It may be due to our "default XXX" feature, we have to ensure it executes
> reliably as possible as it can in case of emergency.
>  In my view, we have been using "isolate" since 2014, better no touch that,
> that's why after some thinking I choose this method. 
The following messages is an example I met during tests when I used "start"
instead of "isolate",
it triggered the Kdump Error Handler twice:
1) One was triggered by the initrd root fs service failure. 2) The other was triggered by
the kdump capture service failure going on


[ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
[DEPEND] Dependency failed for Initrd Root Device.
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[ SKIP ] Ordering cycle found, skipping Initrd Default Target
[DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
[DEPEND] Dependency failed for /sysroot.
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[ SKIP ] Ordering cycle found, skipping Initrd Default Target
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[ SKIP ] Ordering cycle found, skipping Initrd Default Target
[  OK  ] Reached target Initrd File Systems.
[  OK  ] Stopped dracut pre-udev hook.
[   62.773496] audit_printk_skb: 48 callbacks suppressed
[   62.773838] audit: type=1131 audit(1490601290.421:36): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-pre-udev comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
         Starting Kdump Emergency...
[  OK  ] Stopped dracut cmdline hook.
[   62.778038] audit: type=1131 audit(1490601290.425:37): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-cmdline comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
         Starting Setup Virtual Console...
[  OK  ] Stopped dracut initqueue hook.
[   62.784637] audit: type=1130 audit(1490601290.432:38): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   62.786329] audit: type=1131 audit(1490601290.434:39): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  OK  ] Started Kdump Emergency.
[   62.801906] audit: type=1130 audit(1490601290.449:40): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=emergency comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   62.805255] audit: type=1131 audit(1490601290.453:41): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=emergency comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems.
         Starting dracut pre-pivot and cleanup hook...
[  OK  ] Started Setup Virtual Console.
[   62.856032] audit: type=1130 audit(1490601290.503:42): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
         Starting Kdump Error Handler...
Kdump: Executing default action kdump_emergency_shell
Warning: /dev/mapper/fedora-root does not exist

Generating "/run/initramfs/rdsosreport.txt"
[  OK  ] Started dracut pre-pivot and cleanup hook.
[   62.936605] audit: type=1130 audit(1490601290.584:43): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-pre-pivot comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
         Starting Kdump Vmcore Save Service...
[  OK  ] Reached target Emergency Mode.


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


kdump:/# kdump: dump target is
kdump: error: Dump target  is not mounted.
kdump: saving vmcore failed
[FAILED] Failed to start Kdump Vmcore Save Service.
See 'systemctl status kdump-capture.service' for details.
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[   62.995441] audit: type=1130 audit(1490601290.643:44): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=kdump-capture comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
[  OK  ] Stopped target Remote File Systems.
[  OK  ] Stopped target Timers.
[  OK  ] Stopped target Remote File Systems (Pre).
[  OK  ] Stopped target Initrd Default Target.
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Sockets.
[  OK  ] Stopped target System Initialization.
[   63.008279] systemd-journald[764]: Received SIGTERM from PID 1 (systemd).
[   63.009140] systemd[1]: Stopping Journal Service...
         Stopping Journal Service...
[   63.013373] systemd[1]: Stopped Apply Kernel Variables.
[  OK  ] Stopped Apply Kernel Variables.
[   63.016630] audit: type=1131 audit(1490601290.664:45): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=systemd-sysctl comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   63.018835] systemd[1]: Stopped udev Coldplug all Devices.
[  OK  ] Stopped udev Coldplug all Devices.
[   63.021430] systemd[1]: Stopped target Local File Systems.
[  OK  ] Stopped target Local File Systems.
[   63.023394] systemd[1]: Starting Kdump Emergency...
         Starting Kdump Emergency...
[   63.025422] systemd[1]: Stopped target Paths.
[  OK  ] Stopped target Paths.
[   63.026916] systemd[1]: Stopped Dispatch Password Requests to Console Directory Watch.
[  OK  ] Stopped Dispatch Password Requests to Console Directory Watch.
[   63.028824] systemd[1]: Stopped target Initrd File Systems.
[  OK  ] Stopped target Initrd File Systems.
[   63.032734] systemd[1]: Stopped target Swap.
[  OK  ] Stopped target Swap.
[   63.033712] systemd[1]: Stopped target Slices.
[  OK  ] Stopped target Slices.
         Stopping udev Kernel Device Manager...
[  OK  ] Stopped Journal Service.
[  OK  ] Stopped udev Kernel Device Manager.
[  OK  ] Started Kdump Emergency.
[  OK  ] Stopped Kdump Error Handler.
[  OK  ] Listening on Journal Audit Socket.
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.
[  OK  ] Stopped Setup Virtual Console.
[  OK  ] Reached target Slices.
         Starting Apply Kernel Variables...
[  OK  ] Reached target Timers.
         Starting Journal Service...
[  OK  ] Reached target Paths.
[  OK  ] Stopped target Emergency Mode.
[  OK  ] Reached target Swap.
[  OK  ] Reached target Local File Systems.
         Starting dracut cmdline hook...
[  OK  ] Reached target Sockets.
[  OK  ] Started Journal Service.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started dracut cmdline hook.
         Starting dracut pre-udev hook...
[  OK  ] Started dracut pre-udev hook.
         Starting udev Kernel Device Manager...
[  OK  ] Started udev Kernel Device Manager.
         Starting udev Coldplug all Devices...
[  OK  ] Started udev Coldplug all Devices.
         Starting dracut initqueue hook...
[  OK  ] Reached target System Initialization.
[  OK  ] Reached target Basic System.
[ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
[DEPEND] Dependency failed for Initrd Root Device.
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
[DEPEND] Dependency failed for /sysroot.
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[ SKIP ] Ordering cycle found, skipping dracut pre-pivot and cleanup hook
[  OK  ] Stopped target Basic System.
[  OK  ] Reached target Initrd File Systems.
[  OK  ] Stopped target System Initialization.
         Starting Setup Virtual Console...
[  OK  ] Stopped dracut pre-udev hook.
[   93.273790] audit_printk_skb: 45 callbacks suppressed
[   93.274120] audit: type=1131 audit(1490601320.921:61): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-pre-udev comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  OK  ] Stopped dracut cmdline hook.
[   93.283737] audit: type=1131 audit(1490601320.931:62): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-cmdline comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
         Starting Kdump Emergency...
[  OK  ] Stopped dracut initqueue hook.
[   93.295098] audit: type=1130 audit(1490601320.942:63): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   93.300060] audit: type=1131 audit(1490601320.947:64): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  OK  ] Started Kdump Emergency.
[   93.307304] audit: type=1130 audit(1490601320.955:65): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=emergency comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   93.311203] audit: type=1131 audit(1490601320.959:66): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=emergency comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems.
[  OK  ] Reached target Emergency Mode.
[  OK  ] Started Setup Virtual Console.
[   93.344652] audit: type=1130 audit(1490601320.992:67): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
         Starting Kdump Error Handler...
Kdump: Executing default action kdump_emergency_shell
Warning: /dev/mapper/fedora-root does not exist

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


kdump:/#

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Dave Young]

On 03/27/17 at 04:38pm, Xunlei Pang wrote:
>  On 03/27/2017 at 04:25 PM, Dave Young wrote:
>  > On 03/27/17 at 04:03pm, Xunlei Pang wrote:
>  >> On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
>  >>> Hi Xunlei,
>  >>>
>  >>> On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
>  >>>> We met a problem that the kdump emergency service failed to
>  >>>> start when the target dump timeout(we passed "rd.timeout=30"
>  >>>> to kdump), it reported "Transaction is destructive" messages:
>  >>>>
>  >>>>   [ TIME ] Timed out waiting for device
> dev-mapper-fedora\x2droot.device.
>  >>>>   [DEPEND] Dependency failed for Initrd Root Device.
>  >>>>   [ SKIP ] Ordering cycle found, skipping System Initialization
>  >>>>   [DEPEND] Dependency failed for /sysroot.
>  >>>>   [DEPEND] Dependency failed for Initrd Root File System.
>  >>>>   [DEPEND] Dependency failed for Reload Configuration from the Real
> Root.
>  >>>>   [ SKIP ] Ordering cycle found, skipping System Initialization
>  >>>>   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
>  >>>>   [DEPEND] Dependency failed for File System Check on
> /dev/mapper/fedora-root.
>  >>>>   [  OK  ] Reached target Initrd File Systems.
>  >>>>   [  OK  ] Stopped dracut pre-udev hook.
>  >>>>   [  OK  ] Stopped dracut cmdline hook.
>  >>>>            Starting Setup Virtual Console...
>  >>>>            Starting Kdump Emergency...
>  >>>>   [  OK  ] Reached target Initrd Default Target.
>  >>>>   [  OK  ] Stopped dracut initqueue hook.
>  >>>>   Failed to start kdump-error-handler.service: Transaction is
> destructive.
>  >>>>   See system logs and 'systemctl status
> kdump-error-handler.service' for details.
>  >>>>   [FAILED] Failed to start Kdump Emergency.
>  >>>>   See 'systemctl status emergency.service' for details.
>  >>>>   [DEPEND] Dependency failed for Emergency Mode.
>  >>>>
>  >>>> This is because in case of root failure, initrd-root-fs.target
>  >>>> will trigger systemd emergency target which requires the systemd
>  >>>> emergency service actually is kdump-emergency.service, then our
>  >>>> kdump-emergency.service starts kdump-error-handler.service with
>  >>>> "systemctl isolate"(see 99kdumpbase/kdump-emergency.service,
> we
>  >>>> replace systemd's with this one under kdump).
>  >>> I could not understand why kdump emergency.service needs isolate while, it
> is not needed in first kernel (ie in systemd). If kdump would work without isolate then
> probably it will be more closer to upstream systemd and we will need less modifications in
> kdump.
>  >> Yes, what you said is another solution.
>  >>
>  >> Seems Dave has some concern about we may not stop some services like before if
> replacing "isolate" with "start".
>  >> From my tests it is true that some services will be continuing.
>  >>
>  >> Hi Dave, what is you opinion?
>  > I do not remember why we use isolate previously. I thought it is for
>  > force run kdump error handler service so that kdump error handler ensure
>  > not to be blocked by other services.
>  >
>  > Suppose other service can run in an infinite loop, does the "start"
>  > still work for us? For example we expect "default shell" but other
>  > services runs in a loop or something else..
>  >
>  
>  It may be due to our "default XXX" feature, we have to ensure it executes
> reliably as possible as it can in case of emergency.
>  In my view, we have been using "isolate" since 2014, better no touch that,
> that's why after some thinking I choose this method.
>   
It looks good, I think isolate is just right and make sense.

Ack this patch.

Thanks
Dave

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Pratyush Anand]

On Wednesday 29 March 2017 11:33 AM, Dave Young wrote:
>  On 03/27/17 at 04:38pm, Xunlei Pang wrote:
> > On 03/27/2017 at 04:25 PM, Dave Young wrote:
> >> On 03/27/17 at 04:03pm, Xunlei Pang wrote:
> >>> On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
> >>>> Hi Xunlei,
> >>>>
> >>>> On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
> >>>>> We met a problem that the kdump emergency service failed to
> >>>>> start when the target dump timeout(we passed
> "rd.timeout=30"
> >>>>> to kdump), it reported "Transaction is destructive"
> messages:
> >>>>>
> >>>>>   [ TIME ] Timed out waiting for device
> dev-mapper-fedora\x2droot.device.
> >>>>>   [DEPEND] Dependency failed for Initrd Root Device.
> >>>>>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>>>>   [DEPEND] Dependency failed for /sysroot.
> >>>>>   [DEPEND] Dependency failed for Initrd Root File System.
> >>>>>   [DEPEND] Dependency failed for Reload Configuration from the Real
> Root.
> >>>>>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>>>>   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
> >>>>>   [DEPEND] Dependency failed for File System Check on
> /dev/mapper/fedora-root.
> >>>>>   [  OK  ] Reached target Initrd File Systems.
> >>>>>   [  OK  ] Stopped dracut pre-udev hook.
> >>>>>   [  OK  ] Stopped dracut cmdline hook.
> >>>>>            Starting Setup Virtual Console...
> >>>>>            Starting Kdump Emergency...
> >>>>>   [  OK  ] Reached target Initrd Default Target.
> >>>>>   [  OK  ] Stopped dracut initqueue hook.
> >>>>>   Failed to start kdump-error-handler.service: Transaction is
> destructive.
> >>>>>   See system logs and 'systemctl status
> kdump-error-handler.service' for details.
> >>>>>   [FAILED] Failed to start Kdump Emergency.
> >>>>>   See 'systemctl status emergency.service' for details.
> >>>>>   [DEPEND] Dependency failed for Emergency Mode.
> >>>>>
> >>>>> This is because in case of root failure, initrd-root-fs.target
> >>>>> will trigger systemd emergency target which requires the systemd
> >>>>> emergency service actually is kdump-emergency.service, then our
> >>>>> kdump-emergency.service starts kdump-error-handler.service with
> >>>>> "systemctl isolate"(see
> 99kdumpbase/kdump-emergency.service, we
> >>>>> replace systemd's with this one under kdump).
> >>>> I could not understand why kdump emergency.service needs isolate while,
> it is not needed in first kernel (ie in systemd). If kdump would work without isolate then
> probably it will be more closer to upstream systemd and we will need less modifications in
> kdump.
> >>> Yes, what you said is another solution.
> >>>
> >>> Seems Dave has some concern about we may not stop some services like before
> if replacing "isolate" with "start".
> >>> From my tests it is true that some services will be continuing.
> >>>
> >>> Hi Dave, what is you opinion?
> >> I do not remember why we use isolate previously. I thought it is for
> >> force run kdump error handler service so that kdump error handler ensure
> >> not to be blocked by other services.
> >>
> >> Suppose other service can run in an infinite loop, does the "start"
> >> still work for us? For example we expect "default shell" but other
> >> services runs in a loop or something else..
> >>
> >
> > It may be due to our "default XXX" feature, we have to ensure it executes
> reliably as possible as it can in case of emergency.
> > In my view, we have been using "isolate" since 2014, better no touch that,
> that's why after some thinking I choose this method.
> >
>
>  It looks good, I think isolate is just right and make sense.
>
>  Ack this patch. 

Yes, after reading all discussions it seems isolate is a better choice.

Acked-by: Pratyush Anand <panand(a)redhat.com&gt;

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

In this fedora commit, Wang Chao said why he use isolate. Seems it's
mainly used to stop dracut-initqueue lest an infinite loop happen.

commit 002337c6715e442f306b87b92340bef15c4420ac
Author: WANG Chao <chaowang(a)redhat.com&gt;
Date:   Thu May 8 19:37:15 2014 +0800

    Introduce kdump error handling service

On 03/27/17 at 04:03pm, Xunlei Pang wrote:
> On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
> > Hi Xunlei,
> >
> > On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
> >> We met a problem that the kdump emergency service failed to
> >> start when the target dump timeout(we passed "rd.timeout=30"
> >> to kdump), it reported "Transaction is destructive" messages:
> >>
> >>   [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
> >>   [DEPEND] Dependency failed for Initrd Root Device.
> >>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>   [DEPEND] Dependency failed for /sysroot.
> >>   [DEPEND] Dependency failed for Initrd Root File System.
> >>   [DEPEND] Dependency failed for Reload Configuration from the Real Root.
> >>   [ SKIP ] Ordering cycle found, skipping System Initialization
> >>   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
> >>   [DEPEND] Dependency failed for File System Check on
/dev/mapper/fedora-root.
> >>   [  OK  ] Reached target Initrd File Systems.
> >>   [  OK  ] Stopped dracut pre-udev hook.
> >>   [  OK  ] Stopped dracut cmdline hook.
> >>            Starting Setup Virtual Console...
> >>            Starting Kdump Emergency...
> >>   [  OK  ] Reached target Initrd Default Target.
> >>   [  OK  ] Stopped dracut initqueue hook.
> >>   Failed to start kdump-error-handler.service: Transaction is destructive.
> >>   See system logs and 'systemctl status kdump-error-handler.service'
for details.
> >>   [FAILED] Failed to start Kdump Emergency.
> >>   See 'systemctl status emergency.service' for details.
> >>   [DEPEND] Dependency failed for Emergency Mode.
> >>
> >> This is because in case of root failure, initrd-root-fs.target
> >> will trigger systemd emergency target which requires the systemd
> >> emergency service actually is kdump-emergency.service, then our
> >> kdump-emergency.service starts kdump-error-handler.service with
> >> "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
> >> replace systemd's with this one under kdump).
> >
> > I could not understand why kdump emergency.service needs isolate while, it is
not needed in first kernel (ie in systemd). If kdump would work without isolate then
probably it will be more closer to upstream systemd and we will need less modifications in
kdump.
> 
> Yes, what you said is another solution.
> 
> Seems Dave has some concern about we may not stop some services like before if
replacing "isolate" with "start".
> From my tests it is true that some services will be continuing.
> 
> Hi Dave, what is you opinion?
> 
> Regards,
> Xunlei
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 01:10pm, Pratyush Anand wrote:
>  Hi Xunlei,
>  I could not understand why kdump emergency.service needs isolate while, it
>  is not needed in first kernel (ie in systemd). If kdump would work without
>  isolate then probably it will be more closer to upstream systemd and we will
>  need less modifications in kdump. 
OK, I got the reason.

W/o isolate, any error will trigger kdump emergency service. And default
action need be handled in kdump emergence service, namely kdump error
handler. If it's dump to rootfs, it will call "systemctl start
dracut-initqueue"
. However in dracut-initqueue, it will call "systemctl start emergency"
directly, but not on-failure. The infinite loop happens in case the
original failure is triggered in dracut-initqueue.

> 
> ~Pratyush
> > 
> > This will lead to systemd two contradictable jobs queued as an
> > atomic transaction:
> > job 1) the emergency service gets started by initrd-root-fs.target
> > job 2) the emergency service gets stopped due to "systemctl isolate"
> > thereby throwing "Transaction is destructive".
> > 
> > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> > both kdump-emergency.service and kdump-emergency.target to avoid
> > being isolated, then they can keep going on as expected in case
> > of failures.
> > 
> > We add kdump-emergency.target dedicated to kdump the similar way
> > as did for kdump-emergency.service(i.e. will replace systemd's
> > emergency.target with kdump-emergency.target under kdump), and
> > adds "IgnoreOnIsolate=yes" into both of them.
> > 
> > Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> > ---
> >  dracut-kdump-emergency.service |  1 +
> >  dracut-kdump-emergency.target  | 14 ++++++++++++++
> >  dracut-module-setup.sh         |  3 ++-
> >  kexec-tools.spec               |  2 ++
> >  4 files changed, 19 insertions(+), 1 deletion(-)
> >  create mode 100644 dracut-kdump-emergency.target
> > 
> > diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
> > index fb764f2..e023284 100644
> > --- a/dracut-kdump-emergency.service
> > +++ b/dracut-kdump-emergency.service
> > @@ -12,6 +12,7 @@
> >  [Unit]
> >  Description=Kdump Emergency
> >  DefaultDependencies=no
> > +IgnoreOnIsolate=yes
> > 
> >  [Service]
> >  ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
> > diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> > new file mode 100644
> > index 0000000..a1bb493
> > --- /dev/null
> > +++ b/dracut-kdump-emergency.target
> > @@ -0,0 +1,14 @@
> > +#  This file is part of systemd.
> > +#
> > +#  systemd is free software; you can redistribute it and/or modify it
> > +#  under the terms of the GNU Lesser General Public License as published by
> > +#  the Free Software Foundation; either version 2.1 of the License, or
> > +#  (at your option) any later version.
> > +
> > +[Unit]
> > +Description=Emergency Mode
> > +Documentation=man:systemd.special(7)
> > +Requires=emergency.service
> > +After=emergency.service
> > +AllowIsolate=yes
> > +IgnoreOnIsolate=yes
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index 1f96bb8..fa4fa2a 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -734,8 +734,9 @@ install() {
> >      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> >      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
> >      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> > -    # Replace existing emergency service
> > +    # Replace existing emergency service and emergency target
> >      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> > +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
> >      # Also redirect dracut-emergency to kdump error handler
> >      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
> > 
> > diff --git a/kexec-tools.spec b/kexec-tools.spec
> > index 2a176f3..c3359fb 100644
> > --- a/kexec-tools.spec
> > +++ b/kexec-tools.spec
> > @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> >  Source104: dracut-kdump-emergency.service
> >  Source105: dracut-kdump-error-handler.service
> >  Source106: dracut-kdump-capture.service
> > +Source107: dracut-kdump-emergency.target
> > 
> >  Requires(post): systemd-units
> >  Requires(preun): systemd-units
> > @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> >  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
> >  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
> >  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> > +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
> >  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
> >  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
> > 
> > 
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 05:45pm, Baoquan He wrote:
>  On 03/27/17 at 01:10pm, Pratyush Anand wrote:
>  > Hi Xunlei,
>  > I could not understand why kdump emergency.service needs isolate while, it
>  > is not needed in first kernel (ie in systemd). If kdump would work without
>  > isolate then probably it will be more closer to upstream systemd and we will
>  > need less modifications in kdump.
>  
>  OK, I got the reason.
>  
>  W/o isolate, any error will trigger kdump emergency service. And default
>  action need be handled in kdump emergence service, namely kdump error
>  handler. If it's dump to rootfs, it will call "systemctl start
> dracut-initqueue"
>  . However in dracut-initqueue, it will call "systemctl start emergency"
>  directly, but not on-failure. The infinite loop happens in case the
>  original failure is triggered in dracut-initqueue. 
And seems there's thing wong in Wang Chao's comment, I remember,
according to our discussion,  isolate is not to stop other service,
but to stop later new service from being started. isolate could not stop
other running services.

> 
> > 
> > ~Pratyush
> > > 
> > > This will lead to systemd two contradictable jobs queued as an
> > > atomic transaction:
> > > job 1) the emergency service gets started by initrd-root-fs.target
> > > job 2) the emergency service gets stopped due to "systemctl
isolate"
> > > thereby throwing "Transaction is destructive".
> > > 
> > > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> > > both kdump-emergency.service and kdump-emergency.target to avoid
> > > being isolated, then they can keep going on as expected in case
> > > of failures.
> > > 
> > > We add kdump-emergency.target dedicated to kdump the similar way
> > > as did for kdump-emergency.service(i.e. will replace systemd's
> > > emergency.target with kdump-emergency.target under kdump), and
> > > adds "IgnoreOnIsolate=yes" into both of them.
> > > 
> > > Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> > > ---
> > >  dracut-kdump-emergency.service |  1 +
> > >  dracut-kdump-emergency.target  | 14 ++++++++++++++
> > >  dracut-module-setup.sh         |  3 ++-
> > >  kexec-tools.spec               |  2 ++
> > >  4 files changed, 19 insertions(+), 1 deletion(-)
> > >  create mode 100644 dracut-kdump-emergency.target
> > > 
> > > diff --git a/dracut-kdump-emergency.service
b/dracut-kdump-emergency.service
> > > index fb764f2..e023284 100644
> > > --- a/dracut-kdump-emergency.service
> > > +++ b/dracut-kdump-emergency.service
> > > @@ -12,6 +12,7 @@
> > >  [Unit]
> > >  Description=Kdump Emergency
> > >  DefaultDependencies=no
> > > +IgnoreOnIsolate=yes
> > > 
> > >  [Service]
> > >  ExecStart=/usr/bin/systemctl --no-block isolate
kdump-error-handler.service
> > > diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> > > new file mode 100644
> > > index 0000000..a1bb493
> > > --- /dev/null
> > > +++ b/dracut-kdump-emergency.target
> > > @@ -0,0 +1,14 @@
> > > +#  This file is part of systemd.
> > > +#
> > > +#  systemd is free software; you can redistribute it and/or modify it
> > > +#  under the terms of the GNU Lesser General Public License as published
by
> > > +#  the Free Software Foundation; either version 2.1 of the License, or
> > > +#  (at your option) any later version.
> > > +
> > > +[Unit]
> > > +Description=Emergency Mode
> > > +Documentation=man:systemd.special(7)
> > > +Requires=emergency.service
> > > +After=emergency.service
> > > +AllowIsolate=yes
> > > +IgnoreOnIsolate=yes
> > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > > index 1f96bb8..fa4fa2a 100755
> > > --- a/dracut-module-setup.sh
> > > +++ b/dracut-module-setup.sh
> > > @@ -734,8 +734,9 @@ install() {
> > >      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> > >      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
> > >      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> > > -    # Replace existing emergency service
> > > +    # Replace existing emergency service and emergency target
> > >      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> > > +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
> > >      # Also redirect dracut-emergency to kdump error handler
> > >      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
> > > 
> > > diff --git a/kexec-tools.spec b/kexec-tools.spec
> > > index 2a176f3..c3359fb 100644
> > > --- a/kexec-tools.spec
> > > +++ b/kexec-tools.spec
> > > @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> > >  Source104: dracut-kdump-emergency.service
> > >  Source105: dracut-kdump-error-handler.service
> > >  Source106: dracut-kdump-capture.service
> > > +Source107: dracut-kdump-emergency.target
> > > 
> > >  Requires(post): systemd-units
> > >  Requires(preun): systemd-units
> > > @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> > >  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
> > >  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
> > >  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> > > +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
> > >  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
> > >  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
> > > 
> > > 
> > _______________________________________________
> > kexec mailing list -- kexec(a)lists.fedoraproject.org
> > To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/27/2017 at 05:51 PM, Baoquan He wrote:
>  On 03/27/17 at 05:45pm, Baoquan He wrote:
> > On 03/27/17 at 01:10pm, Pratyush Anand wrote:
> >> Hi Xunlei,
> >> I could not understand why kdump emergency.service needs isolate while, it
> >> is not needed in first kernel (ie in systemd). If kdump would work without
> >> isolate then probably it will be more closer to upstream systemd and we will
> >> need less modifications in kdump.
> > OK, I got the reason.
> >
> > W/o isolate, any error will trigger kdump emergency service. And default
> > action need be handled in kdump emergence service, namely kdump error
> > handler. If it's dump to rootfs, it will call "systemctl start
> dracut-initqueue"
> > . However in dracut-initqueue, it will call "systemctl start emergency"
> > directly, but not on-failure. The infinite loop happens in case the
> > original failure is triggered in dracut-initqueue.
>  And seems there's thing wong in Wang Chao's comment, I remember,
>  according to our discussion,  isolate is not to stop other service,
>  but to stop later new service from being started. isolate could not stop
>  other running services. 
Should be "to stop current running services" when "systemctl isolate"
is executed.
For example, "dump_to_rootfs" will execute "systemctl start
dracut-initqueue", then
if it is "to stop later new service from being started", we will never be able
to start
any new service in case of emergency.

Regards,
Xunlei

> >> ~Pratyush
> >>> This will lead to systemd two contradictable jobs queued as an
> >>> atomic transaction:
> >>> job 1) the emergency service gets started by initrd-root-fs.target
> >>> job 2) the emergency service gets stopped due to "systemctl
> isolate"
> >>> thereby throwing "Transaction is destructive".
> >>>
> >>> In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> >>> both kdump-emergency.service and kdump-emergency.target to avoid
> >>> being isolated, then they can keep going on as expected in case
> >>> of failures.
> >>>
> >>> We add kdump-emergency.target dedicated to kdump the similar way
> >>> as did for kdump-emergency.service(i.e. will replace systemd's
> >>> emergency.target with kdump-emergency.target under kdump), and
> >>> adds "IgnoreOnIsolate=yes" into both of them.
> >>>
> >>> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> >>> ---
> >>>  dracut-kdump-emergency.service |  1 +
> >>>  dracut-kdump-emergency.target  | 14 ++++++++++++++
> >>>  dracut-module-setup.sh         |  3 ++-
> >>>  kexec-tools.spec               |  2 ++
> >>>  4 files changed, 19 insertions(+), 1 deletion(-)
> >>>  create mode 100644 dracut-kdump-emergency.target
> >>>
> >>> diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
> >>> index fb764f2..e023284 100644
> >>> --- a/dracut-kdump-emergency.service
> >>> +++ b/dracut-kdump-emergency.service
> >>> @@ -12,6 +12,7 @@
> >>>  [Unit]
> >>>  Description=Kdump Emergency
> >>>  DefaultDependencies=no
> >>> +IgnoreOnIsolate=yes
> >>>
> >>>  [Service]
> >>>  ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
> >>> diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> >>> new file mode 100644
> >>> index 0000000..a1bb493
> >>> --- /dev/null
> >>> +++ b/dracut-kdump-emergency.target
> >>> @@ -0,0 +1,14 @@
> >>> +#  This file is part of systemd.
> >>> +#
> >>> +#  systemd is free software; you can redistribute it and/or modify it
> >>> +#  under the terms of the GNU Lesser General Public License as published by
> >>> +#  the Free Software Foundation; either version 2.1 of the License, or
> >>> +#  (at your option) any later version.
> >>> +
> >>> +[Unit]
> >>> +Description=Emergency Mode
> >>> +Documentation=man:systemd.special(7)
> >>> +Requires=emergency.service
> >>> +After=emergency.service
> >>> +AllowIsolate=yes
> >>> +IgnoreOnIsolate=yes
> >>> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> >>> index 1f96bb8..fa4fa2a 100755
> >>> --- a/dracut-module-setup.sh
> >>> +++ b/dracut-module-setup.sh
> >>> @@ -734,8 +734,9 @@ install() {
> >>>      ln_r "$systemdsystemunitdir/kdump-capture.service"
> "$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> >>>      inst "$moddir/kdump-error-handler.sh"
> "/usr/bin/kdump-error-handler.sh"
> >>>      inst "$moddir/kdump-error-handler.service"
> "$systemdsystemunitdir/kdump-error-handler.service"
> >>> -    # Replace existing emergency service
> >>> +    # Replace existing emergency service and emergency target
> >>>      cp "$moddir/kdump-emergency.service"
> "$initdir/$systemdsystemunitdir/emergency.service"
> >>> +    cp "$moddir/kdump-emergency.target"
> "$initdir/$systemdsystemunitdir/emergency.target"
> >>>      # Also redirect dracut-emergency to kdump error handler
> >>>      ln_r "$systemdsystemunitdir/emergency.service"
> "$systemdsystemunitdir/dracut-emergency.service"
> >>>
> >>> diff --git a/kexec-tools.spec b/kexec-tools.spec
> >>> index 2a176f3..c3359fb 100644
> >>> --- a/kexec-tools.spec
> >>> +++ b/kexec-tools.spec
> >>> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> >>>  Source104: dracut-kdump-emergency.service
> >>>  Source105: dracut-kdump-error-handler.service
> >>>  Source106: dracut-kdump-capture.service
> >>> +Source107: dracut-kdump-emergency.target
> >>>
> >>>  Requires(post): systemd-units
> >>>  Requires(preun): systemd-units
> >>> @@ -197,6 +198,7 @@ cp %{SOURCE103}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> >>>  cp %{SOURCE104}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE104}}
> >>>  cp %{SOURCE105}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE105}}
> >>>  cp %{SOURCE106}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE106}}
> >>> +cp %{SOURCE107}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE107}}
> >>>  chmod 755
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE100}}
> >>>  chmod 755
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE101}}
> >>>
> >>>
> >> _______________________________________________
> >> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 06:46pm, Xunlei Pang wrote:
>  On 03/27/2017 at 05:51 PM, Baoquan He wrote:
>  > On 03/27/17 at 05:45pm, Baoquan He wrote:
>  >> On 03/27/17 at 01:10pm, Pratyush Anand wrote:
>  >>> Hi Xunlei,
>  >>> I could not understand why kdump emergency.service needs isolate while, it
>  >>> is not needed in first kernel (ie in systemd). If kdump would work without
>  >>> isolate then probably it will be more closer to upstream systemd and we
> will
>  >>> need less modifications in kdump.
>  >> OK, I got the reason.
>  >>
>  >> W/o isolate, any error will trigger kdump emergency service. And default
>  >> action need be handled in kdump emergence service, namely kdump error
>  >> handler. If it's dump to rootfs, it will call "systemctl start
> dracut-initqueue"
>  >> . However in dracut-initqueue, it will call "systemctl start
> emergency"
>  >> directly, but not on-failure. The infinite loop happens in case the
>  >> original failure is triggered in dracut-initqueue.
>  > And seems there's thing wong in Wang Chao's comment, I remember,
>  > according to our discussion,  isolate is not to stop other service,
>  > but to stop later new service from being started. isolate could not stop
>  > other running services.
>  
>  Should be "to stop current running services" when "systemctl isolate"
> is executed.
>  For example, "dump_to_rootfs" will execute "systemctl start
> dracut-initqueue", then 
Seems no. Here we execute "systemctl start dracut-initqueue" just
because we can't use systemd service mechanism, the reaons is simple,
isolate is specified in kdump service.

"systemctl start dracut-initqueue" is running command, like we start a
user space program, not by service starting way. My understanding.

Hi Xunlei,

I vaguely remember you are gonna to cleanup away dump to rootfs, then
maybe removing kdump error handler is a choice. Like Pratyush, making it
be consistent with dracut/systemd behaviour is better for our code
maintaining. Personnal opinion.

Thanks
Baoquan

> if it is "to stop later new service from being started", we will never be
able to start
> any new service in case of emergency.
> 
> Regards,
> Xunlei
> 
> >
> >>> ~Pratyush
> >>>> This will lead to systemd two contradictable jobs queued as an
> >>>> atomic transaction:
> >>>> job 1) the emergency service gets started by initrd-root-fs.target
> >>>> job 2) the emergency service gets stopped due to "systemctl
isolate"
> >>>> thereby throwing "Transaction is destructive".
> >>>>
> >>>> In order to solve it, we can utilize "IgnoreOnIsolate=yes"
for
> >>>> both kdump-emergency.service and kdump-emergency.target to avoid
> >>>> being isolated, then they can keep going on as expected in case
> >>>> of failures.
> >>>>
> >>>> We add kdump-emergency.target dedicated to kdump the similar way
> >>>> as did for kdump-emergency.service(i.e. will replace systemd's
> >>>> emergency.target with kdump-emergency.target under kdump), and
> >>>> adds "IgnoreOnIsolate=yes" into both of them.
> >>>>
> >>>> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> >>>> ---
> >>>>  dracut-kdump-emergency.service |  1 +
> >>>>  dracut-kdump-emergency.target  | 14 ++++++++++++++
> >>>>  dracut-module-setup.sh         |  3 ++-
> >>>>  kexec-tools.spec               |  2 ++
> >>>>  4 files changed, 19 insertions(+), 1 deletion(-)
> >>>>  create mode 100644 dracut-kdump-emergency.target
> >>>>
> >>>> diff --git a/dracut-kdump-emergency.service
b/dracut-kdump-emergency.service
> >>>> index fb764f2..e023284 100644
> >>>> --- a/dracut-kdump-emergency.service
> >>>> +++ b/dracut-kdump-emergency.service
> >>>> @@ -12,6 +12,7 @@
> >>>>  [Unit]
> >>>>  Description=Kdump Emergency
> >>>>  DefaultDependencies=no
> >>>> +IgnoreOnIsolate=yes
> >>>>
> >>>>  [Service]
> >>>>  ExecStart=/usr/bin/systemctl --no-block isolate
kdump-error-handler.service
> >>>> diff --git a/dracut-kdump-emergency.target
b/dracut-kdump-emergency.target
> >>>> new file mode 100644
> >>>> index 0000000..a1bb493
> >>>> --- /dev/null
> >>>> +++ b/dracut-kdump-emergency.target
> >>>> @@ -0,0 +1,14 @@
> >>>> +#  This file is part of systemd.
> >>>> +#
> >>>> +#  systemd is free software; you can redistribute it and/or modify
it
> >>>> +#  under the terms of the GNU Lesser General Public License as
published by
> >>>> +#  the Free Software Foundation; either version 2.1 of the License,
or
> >>>> +#  (at your option) any later version.
> >>>> +
> >>>> +[Unit]
> >>>> +Description=Emergency Mode
> >>>> +Documentation=man:systemd.special(7)
> >>>> +Requires=emergency.service
> >>>> +After=emergency.service
> >>>> +AllowIsolate=yes
> >>>> +IgnoreOnIsolate=yes
> >>>> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> >>>> index 1f96bb8..fa4fa2a 100755
> >>>> --- a/dracut-module-setup.sh
> >>>> +++ b/dracut-module-setup.sh
> >>>> @@ -734,8 +734,9 @@ install() {
> >>>>      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> >>>>      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
> >>>>      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> >>>> -    # Replace existing emergency service
> >>>> +    # Replace existing emergency service and emergency target
> >>>>      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> >>>> +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
> >>>>      # Also redirect dracut-emergency to kdump error handler
> >>>>      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
> >>>>
> >>>> diff --git a/kexec-tools.spec b/kexec-tools.spec
> >>>> index 2a176f3..c3359fb 100644
> >>>> --- a/kexec-tools.spec
> >>>> +++ b/kexec-tools.spec
> >>>> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> >>>>  Source104: dracut-kdump-emergency.service
> >>>>  Source105: dracut-kdump-error-handler.service
> >>>>  Source106: dracut-kdump-capture.service
> >>>> +Source107: dracut-kdump-emergency.target
> >>>>
> >>>>  Requires(post): systemd-units
> >>>>  Requires(preun): systemd-units
> >>>> @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> >>>>  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
> >>>>  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
> >>>>  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> >>>> +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
> >>>>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
> >>>>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
> >>>>
> >>>>
> >>> _______________________________________________
> >>> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >>> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/27/2017 at 06:55 PM, Baoquan He wrote:
>  On 03/27/17 at 06:46pm, Xunlei Pang wrote:
> > On 03/27/2017 at 05:51 PM, Baoquan He wrote:
> >> On 03/27/17 at 05:45pm, Baoquan He wrote:
> >>> On 03/27/17 at 01:10pm, Pratyush Anand wrote:
> >>>> Hi Xunlei,
> >>>> I could not understand why kdump emergency.service needs isolate while,
> it
> >>>> is not needed in first kernel (ie in systemd). If kdump would work
> without
> >>>> isolate then probably it will be more closer to upstream systemd and we
> will
> >>>> need less modifications in kdump.
> >>> OK, I got the reason.
> >>>
> >>> W/o isolate, any error will trigger kdump emergency service. And default
> >>> action need be handled in kdump emergence service, namely kdump error
> >>> handler. If it's dump to rootfs, it will call "systemctl start
> dracut-initqueue"
> >>> . However in dracut-initqueue, it will call "systemctl start
> emergency"
> >>> directly, but not on-failure. The infinite loop happens in case the
> >>> original failure is triggered in dracut-initqueue.
> >> And seems there's thing wong in Wang Chao's comment, I remember,
> >> according to our discussion,  isolate is not to stop other service,
> >> but to stop later new service from being started. isolate could not stop
> >> other running services.
> > Should be "to stop current running services" when "systemctl
> isolate" is executed.
> > For example, "dump_to_rootfs" will execute "systemctl start
> dracut-initqueue", then
>  Seems no. Here we execute "systemctl start dracut-initqueue" just
>  because we can't use systemd service mechanism, the reaons is simple,
>  isolate is specified in kdump service.
>
>  "systemctl start dracut-initqueue" is running command, like we start a
>  user space program, not by service starting way. My understanding. 
This is beyond my head, from my understanding "systemctl start dracut-initqueue"
should
equal "systemctl start dracut-initqueue.service", just like "systemctl
start sysroot" equals
"systemctl start sysroot.mount".

>  Hi Xunlei,
>
>  I vaguely remember you are gonna to cleanup away dump to rootfs, then
>  maybe removing kdump error handler is a choice. Like Pratyush, making it 
I don't have such plan, which BZ# do you mean?

>  be consistent with dracut/systemd behaviour is better for our code
>  maintaining. Personnal opinion. 
Currently using "start" instead of "isolate" is problematic, we have
to discuss further and
figure out a new way if wanting to be align with systemd/dracut behaviour.

Regards,
Xunlei

>  Thanks
>  Baoquan
>
> > if it is "to stop later new service from being started", we will never be
> able to start
> > any new service in case of emergency.
> >
> > Regards,
> > Xunlei
> >
> >>>> ~Pratyush
> >>>>> This will lead to systemd two contradictable jobs queued as an
> >>>>> atomic transaction:
> >>>>> job 1) the emergency service gets started by initrd-root-fs.target
> >>>>> job 2) the emergency service gets stopped due to "systemctl
> isolate"
> >>>>> thereby throwing "Transaction is destructive".
> >>>>>
> >>>>> In order to solve it, we can utilize "IgnoreOnIsolate=yes"
> for
> >>>>> both kdump-emergency.service and kdump-emergency.target to avoid
> >>>>> being isolated, then they can keep going on as expected in case
> >>>>> of failures.
> >>>>>
> >>>>> We add kdump-emergency.target dedicated to kdump the similar way
> >>>>> as did for kdump-emergency.service(i.e. will replace systemd's
> >>>>> emergency.target with kdump-emergency.target under kdump), and
> >>>>> adds "IgnoreOnIsolate=yes" into both of them.
> >>>>>
> >>>>> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> >>>>> ---
> >>>>>  dracut-kdump-emergency.service |  1 +
> >>>>>  dracut-kdump-emergency.target  | 14 ++++++++++++++
> >>>>>  dracut-module-setup.sh         |  3 ++-
> >>>>>  kexec-tools.spec               |  2 ++
> >>>>>  4 files changed, 19 insertions(+), 1 deletion(-)
> >>>>>  create mode 100644 dracut-kdump-emergency.target
> >>>>>
> >>>>> diff --git a/dracut-kdump-emergency.service
> b/dracut-kdump-emergency.service
> >>>>> index fb764f2..e023284 100644
> >>>>> --- a/dracut-kdump-emergency.service
> >>>>> +++ b/dracut-kdump-emergency.service
> >>>>> @@ -12,6 +12,7 @@
> >>>>>  [Unit]
> >>>>>  Description=Kdump Emergency
> >>>>>  DefaultDependencies=no
> >>>>> +IgnoreOnIsolate=yes
> >>>>>
> >>>>>  [Service]
> >>>>>  ExecStart=/usr/bin/systemctl --no-block isolate
> kdump-error-handler.service
> >>>>> diff --git a/dracut-kdump-emergency.target
> b/dracut-kdump-emergency.target
> >>>>> new file mode 100644
> >>>>> index 0000000..a1bb493
> >>>>> --- /dev/null
> >>>>> +++ b/dracut-kdump-emergency.target
> >>>>> @@ -0,0 +1,14 @@
> >>>>> +#  This file is part of systemd.
> >>>>> +#
> >>>>> +#  systemd is free software; you can redistribute it and/or modify
> it
> >>>>> +#  under the terms of the GNU Lesser General Public License as
> published by
> >>>>> +#  the Free Software Foundation; either version 2.1 of the License,
> or
> >>>>> +#  (at your option) any later version.
> >>>>> +
> >>>>> +[Unit]
> >>>>> +Description=Emergency Mode
> >>>>> +Documentation=man:systemd.special(7)
> >>>>> +Requires=emergency.service
> >>>>> +After=emergency.service
> >>>>> +AllowIsolate=yes
> >>>>> +IgnoreOnIsolate=yes
> >>>>> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> >>>>> index 1f96bb8..fa4fa2a 100755
> >>>>> --- a/dracut-module-setup.sh
> >>>>> +++ b/dracut-module-setup.sh
> >>>>> @@ -734,8 +734,9 @@ install() {
> >>>>>      ln_r "$systemdsystemunitdir/kdump-capture.service"
> "$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> >>>>>      inst "$moddir/kdump-error-handler.sh"
> "/usr/bin/kdump-error-handler.sh"
> >>>>>      inst "$moddir/kdump-error-handler.service"
> "$systemdsystemunitdir/kdump-error-handler.service"
> >>>>> -    # Replace existing emergency service
> >>>>> +    # Replace existing emergency service and emergency target
> >>>>>      cp "$moddir/kdump-emergency.service"
> "$initdir/$systemdsystemunitdir/emergency.service"
> >>>>> +    cp "$moddir/kdump-emergency.target"
> "$initdir/$systemdsystemunitdir/emergency.target"
> >>>>>      # Also redirect dracut-emergency to kdump error handler
> >>>>>      ln_r "$systemdsystemunitdir/emergency.service"
> "$systemdsystemunitdir/dracut-emergency.service"
> >>>>>
> >>>>> diff --git a/kexec-tools.spec b/kexec-tools.spec
> >>>>> index 2a176f3..c3359fb 100644
> >>>>> --- a/kexec-tools.spec
> >>>>> +++ b/kexec-tools.spec
> >>>>> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> >>>>>  Source104: dracut-kdump-emergency.service
> >>>>>  Source105: dracut-kdump-error-handler.service
> >>>>>  Source106: dracut-kdump-capture.service
> >>>>> +Source107: dracut-kdump-emergency.target
> >>>>>
> >>>>>  Requires(post): systemd-units
> >>>>>  Requires(preun): systemd-units
> >>>>> @@ -197,6 +198,7 @@ cp %{SOURCE103}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> >>>>>  cp %{SOURCE104}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE104}}
> >>>>>  cp %{SOURCE105}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE105}}
> >>>>>  cp %{SOURCE106}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE106}}
> >>>>> +cp %{SOURCE107}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE107}}
> >>>>>  chmod 755
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE100}}
> >>>>>  chmod 755
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE101}}
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >>>> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> > _______________________________________________
> > kexec mailing list -- kexec(a)lists.fedoraproject.org
> > To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 07:18pm, Xunlei Pang wrote:
>  >> Should be "to stop current running services" when
> "systemctl isolate" is executed.
>  >> For example, "dump_to_rootfs" will execute "systemctl start
> dracut-initqueue", then
>  > Seems no. Here we execute "systemctl start dracut-initqueue" just
>  > because we can't use systemd service mechanism, the reaons is simple,
>  > isolate is specified in kdump service.
>  >
>  > "systemctl start dracut-initqueue" is running command, like we start a
>  > user space program, not by service starting way. My understanding.
>  
>  This is beyond my head, from my understanding "systemctl start
> dracut-initqueue" should
>  equal "systemctl start dracut-initqueue.service", just like "systemctl
> start sysroot" equals
>  "systemctl start sysroot.mount". 
You are right. I regretted when I re-read it. But as you said, just dump
to root fs is executed in a isolate kdump emergency service, the new
service started by systemctl start dracut-initqueue won't be really
started by systemd. It's later new service relative to kdump emergency
service.

>  
>  >
>  > Hi Xunlei,
>  >
>  > I vaguely remember you are gonna to cleanup away dump to rootfs, then
>  > maybe removing kdump error handler is a choice. Like Pratyush, making it
>  
>  I don't have such plan, which BZ# do you mean? 
Never mind, could be I remember it wrongly.

>  
>  > be consistent with dracut/systemd behaviour is better for our code
>  > maintaining. Personnal opinion.
>  
>  Currently using "start" instead of "isolate" is problematic, we have
> to discuss further and
>  figure out a new way if wanting to be align with systemd/dracut behaviour. 
Yeah, if we can, that surely is better.

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/27/2017 at 07:33 PM, Baoquan He wrote:
>  On 03/27/17 at 07:18pm, Xunlei Pang wrote:
> >>> Should be "to stop current running services" when "systemctl
> isolate" is executed.
> >>> For example, "dump_to_rootfs" will execute "systemctl start
> dracut-initqueue", then
> >> Seems no. Here we execute "systemctl start dracut-initqueue" just
> >> because we can't use systemd service mechanism, the reaons is simple,
> >> isolate is specified in kdump service.
> >>
> >> "systemctl start dracut-initqueue" is running command, like we start a
> >> user space program, not by service starting way. My understanding.
> > This is beyond my head, from my understanding "systemctl start
> dracut-initqueue" should
> > equal "systemctl start dracut-initqueue.service", just like "systemctl
> start sysroot" equals
> > "systemctl start sysroot.mount".
>  You are right. I regretted when I re-read it. But as you said, just dump
>  to root fs is executed in a isolate kdump emergency service, the new
>  service started by systemctl start dracut-initqueue won't be really
>  started by systemd. It's later new service relative to kdump emergency
>  service.
>
> >> Hi Xunlei,
> >>
> >> I vaguely remember you are gonna to cleanup away dump to rootfs, then
> >> maybe removing kdump error handler is a choice. Like Pratyush, making it
> > I don't have such plan, which BZ# do you mean?
>  Never mind, could be I remember it wrongly.
>
> >> be consistent with dracut/systemd behaviour is better for our code
> >> maintaining. Personnal opinion.
> > Currently using "start" instead of "isolate" is problematic, we
> have to discuss further and
> > figure out a new way if wanting to be align with systemd/dracut behaviour.
>  Yeah, if we can, that surely is better.
>  
Reading more code, and return here I'd like to throw out some personal view as well:

There is one key issue that commit 002337c67 ("Introduce kdump error handling
service")
tries to address besides "the initqueue issue", as the changelog says:
    "By default systemd provides an emergency service which will drop us into
    shell every time upon a critical failure. It's very convenient for us to
    re-use the framework of systemd emergency, because we don't have to
    touch the other parts of systemd. We can use our own script instead of
    the default one.
   
    This new scheme will overwrite emergency shell and replace with kdump
    error handling code. And this code will do the error handling as needed.
    Now, we will not rely on dracut-pre-pivot hook running always. Instead
    whenever error happens and it is serious enough that emergency shell
    needed to run, now kdump error handler will run.
   
    dracut-emergency is also replaced by kdump error handler and it's
    enabled again all the way down. So all the failure (including systemd
    and dracut) in 2nd kernel could be captured, and trigger kdump error
    handler."


Now if any error happens at any systemd/dracut boot stage, we can trigger kdump
error handler with the help of replacing systemd/dracut emergency services in WANG
Chao's patch(i.e. commit 002337c67).

This is the biggest advantage of WANG Chao 's design, I can't think of a better
way
currently except adding hooks in dracut for kdump, any good idea?

On the other hand, there is also one "isolate" example in
"98systemd/emergency.service":
    "ExecStopPost=-/usr/bin/systemctl --no-block isolate default.target"

although it is for "ExecStopPost=", not sure if we use "isolate" in
kdump emergency service
will be regarded as not align with systemd/dracut behaviour.

Regards,
Xunlei

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 08:44pm, Xunlei Pang wrote:
>  On 03/27/2017 at 07:33 PM, Baoquan He wrote:
>  >>> be consistent with dracut/systemd behaviour is better for our code
>  >>> maintaining. Personnal opinion.
>  >> Currently using "start" instead of "isolate" is problematic,
> we have to discuss further and
>  >> figure out a new way if wanting to be align with systemd/dracut behaviour.
>  > Yeah, if we can, that surely is better.
>  >
>  
>  Reading more code, and return here I'd like to throw out some personal view as well:
>  
>  There is one key issue that commit 002337c67 ("Introduce kdump error handling
> service")
>  tries to address besides "the initqueue issue", as the changelog says:
>      "By default systemd provides an emergency service which will drop us into
>      shell every time upon a critical failure. It's very convenient for us to
>      re-use the framework of systemd emergency, because we don't have to
>      touch the other parts of systemd. We can use our own script instead of
>      the default one.
>     
>      This new scheme will overwrite emergency shell and replace with kdump
>      error handling code. And this code will do the error handling as needed.
>      Now, we will not rely on dracut-pre-pivot hook running always. Instead
>      whenever error happens and it is serious enough that emergency shell
>      needed to run, now kdump error handler will run.
>     
>      dracut-emergency is also replaced by kdump error handler and it's
>      enabled again all the way down. So all the failure (including systemd
>      and dracut) in 2nd kernel could be captured, and trigger kdump error
>      handler."
>  
>  
>  Now if any error happens at any systemd/dracut boot stage, we can trigger kdump
>  error handler with the help of replacing systemd/dracut emergency services in WANG
>  Chao's patch(i.e. commit 002337c67).
>  
>  This is the biggest advantage of WANG Chao 's design, I can't think of a better
> way
>  currently except adding hooks in dracut for kdump, any good idea? 
Seems no better way to do this. Both dracut and systemd make emergency
reaction as entering into emergency shell. While kdump customers want
the action as the one they specified in "default xxx" in
/etc/kdump.conf. Otherwise we have to embed our special handling code
into dracut, this is what I ever did. But that is too ugly and has been
removed.

And isolate is to break the loop which default action specified as
dump_to_rootfs may cause.

So seems the current way is the best way we can do.

>  
>  On the other hand, there is also one "isolate" example in
> "98systemd/emergency.service":
>      "ExecStopPost=-/usr/bin/systemctl --no-block isolate default.target"
>  
>  although it is for "ExecStopPost=", not sure if we use "isolate" in
> kdump emergency service
>  will be regarded as not align with systemd/dracut behaviour. 
We just try our best to align with upstream behaviour. If have to not,
then we can accept. I think whatever it is, it's worth making it clear.
Now I believe we all know what and why those are, can adjust anytime
when necessary.

Thanks
Baoquan

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/28/2017 at 09:03 AM, Baoquan He wrote:
>  On 03/27/17 at 08:44pm, Xunlei Pang wrote:
> > On 03/27/2017 at 07:33 PM, Baoquan He wrote:
> >>>> be consistent with dracut/systemd behaviour is better for our code
> >>>> maintaining. Personnal opinion.
> >>> Currently using "start" instead of "isolate" is
> problematic, we have to discuss further and
> >>> figure out a new way if wanting to be align with systemd/dracut behaviour.
> >> Yeah, if we can, that surely is better.
> >>
> > Reading more code, and return here I'd like to throw out some personal view as
> well:
> >
> > There is one key issue that commit 002337c67 ("Introduce kdump error handling
> service")
> > tries to address besides "the initqueue issue", as the changelog says:
> >     "By default systemd provides an emergency service which will drop us into
> >     shell every time upon a critical failure. It's very convenient for us to
> >     re-use the framework of systemd emergency, because we don't have to
> >     touch the other parts of systemd. We can use our own script instead of
> >     the default one.
> >    
> >     This new scheme will overwrite emergency shell and replace with kdump
> >     error handling code. And this code will do the error handling as needed.
> >     Now, we will not rely on dracut-pre-pivot hook running always. Instead
> >     whenever error happens and it is serious enough that emergency shell
> >     needed to run, now kdump error handler will run.
> >    
> >     dracut-emergency is also replaced by kdump error handler and it's
> >     enabled again all the way down. So all the failure (including systemd
> >     and dracut) in 2nd kernel could be captured, and trigger kdump error
> >     handler."
> >
> >
> > Now if any error happens at any systemd/dracut boot stage, we can trigger kdump
> > error handler with the help of replacing systemd/dracut emergency services in WANG
> > Chao's patch(i.e. commit 002337c67).
> >
> > This is the biggest advantage of WANG Chao 's design, I can't think of a
> better way
> > currently except adding hooks in dracut for kdump, any good idea?
>  Seems no better way to do this. Both dracut and systemd make emergency
>  reaction as entering into emergency shell. While kdump customers want
>  the action as the one they specified in "default xxx" in
>  /etc/kdump.conf. Otherwise we have to embed our special handling code
>  into dracut, this is what I ever did. But that is too ugly and has been
>  removed. 
Yes, agree.

>  And isolate is to break the loop which default action specified as
>  dump_to_rootfs may cause. 
I personally like replacing "isolate" with "start" as well, as
it's simple and straightforward.

Maybe we could eliminate the "dump_to_rootfs" loop issue by replacing
dump_to_rootfs'
"systemctl start dracut-initqueue" with calling "/bin/initqueue"
directly?

But except that, there are two other known problems I've met if using
"start" instead:
1) In case of failure, kdump-capture.service will still be started by initrd.target,
    finally we will trigger kdump emergency shell twice.
2) Some systemd services are not stopped like before, i.e. we will have more services
    running with kdump error handler service.

If the above-mentioned problems(and potential concerns) can be correctly
resolved/accepted,
I think we can do it.

Regards,
Xunlei

>  So seems the current way is the best way we can do.
>
> > On the other hand, there is also one "isolate" example in
> "98systemd/emergency.service":
> >     "ExecStopPost=-/usr/bin/systemctl --no-block isolate default.target"
> >
> > although it is for "ExecStopPost=", not sure if we use "isolate"
> in kdump emergency service
> > will be regarded as not align with systemd/dracut behaviour.
>  We just try our best to align with upstream behaviour. If have to not,
>  then we can accept. I think whatever it is, it's worth making it clear.
>  Now I believe we all know what and why those are, can adjust anytime
>  when necessary.
>
>  Thanks
>  Baoquan

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/28/17 at 09:28am, Xunlei Pang wrote:
>  On 03/28/2017 at 09:03 AM, Baoquan He wrote:
>  >> This is the biggest advantage of WANG Chao 's design, I can't think of a
> better way
>  >> currently except adding hooks in dracut for kdump, any good idea?
>  > Seems no better way to do this. Both dracut and systemd make emergency
>  > reaction as entering into emergency shell. While kdump customers want
>  > the action as the one they specified in "default xxx" in
>  > /etc/kdump.conf. Otherwise we have to embed our special handling code
>  > into dracut, this is what I ever did. But that is too ugly and has been
>  > removed.
>  
>  Yes, agree.
>  
>  >
>  > And isolate is to break the loop which default action specified as
>  > dump_to_rootfs may cause.
>  
>  I personally like replacing "isolate" with "start" as well, as
> it's simple and straightforward.
>  
>  Maybe we could eliminate the "dump_to_rootfs" loop issue by replacing
> dump_to_rootfs'
>  "systemctl start dracut-initqueue" with calling "/bin/initqueue"
> directly? 
I am not sure if that is OK. In service some env variables are set.
Maybe a test can be take to check.

>  
>  But except that, there are two other known problems I've met if using
> "start" instead:
>  1) In case of failure, kdump-capture.service will still be started by initrd.target,
>      finally we will trigger kdump emergency shell twice.
>  2) Some systemd services are not stopped like before, i.e. we will have more services
>      running with kdump error handler service.
>  
>  If the above-mentioned problems(and potential concerns) can be correctly
> resolved/accepted,
>  I think we can do it. 
Yes, agree. So then for the time bing we can leave it as is, do not
pursuit non-isolate service. If later have a good chance, can make it.

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/28/2017 at 03:26 PM, Baoquan He wrote:
>  On 03/28/17 at 09:28am, Xunlei Pang wrote:
> > On 03/28/2017 at 09:03 AM, Baoquan He wrote:
> >>> This is the biggest advantage of WANG Chao 's design, I can't think
> of a better way
> >>> currently except adding hooks in dracut for kdump, any good idea?
> >> Seems no better way to do this. Both dracut and systemd make emergency
> >> reaction as entering into emergency shell. While kdump customers want
> >> the action as the one they specified in "default xxx" in
> >> /etc/kdump.conf. Otherwise we have to embed our special handling code
> >> into dracut, this is what I ever did. But that is too ugly and has been
> >> removed.
> > Yes, agree.
> >
> >> And isolate is to break the loop which default action specified as
> >> dump_to_rootfs may cause.
> > I personally like replacing "isolate" with "start" as well, as
> it's simple and straightforward.
> >
> > Maybe we could eliminate the "dump_to_rootfs" loop issue by replacing
> dump_to_rootfs'
> > "systemctl start dracut-initqueue" with calling "/bin/initqueue"
> directly?
>  I am not sure if that is OK. In service some env variables are set.
>  Maybe a test can be take to check.
>
> > But except that, there are two other known problems I've met if using
> "start" instead:
> > 1) In case of failure, kdump-capture.service will still be started by initrd.target,
> >     finally we will trigger kdump emergency shell twice.
> > 2) Some systemd services are not stopped like before, i.e. we will have more
> services
> >     running with kdump error handler service.
> >
> > If the above-mentioned problems(and potential concerns) can be correctly
> resolved/accepted,
> > I think we can do it.
>  Yes, agree. So then for the time bing we can leave it as is, do not
>  pursuit non-isolate service. If later have a good chance, can make it.
>  
Ok, I have no objection on this, thanks for review.

Regards,
Xunlei

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Dave Young]

On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  We met a problem that the kdump emergency service failed to
>  start when the target dump timeout(we passed "rd.timeout=30"
>  to kdump), it reported "Transaction is destructive" messages:
>  
>    [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
>    [DEPEND] Dependency failed for Initrd Root Device.
>    [ SKIP ] Ordering cycle found, skipping System Initialization
>    [DEPEND] Dependency failed for /sysroot.
>    [DEPEND] Dependency failed for Initrd Root File System.
>    [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>    [ SKIP ] Ordering cycle found, skipping System Initialization
>    [ SKIP ] Ordering cycle found, skipping Initrd Default Target
>    [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
>    [  OK  ] Reached target Initrd File Systems.
>    [  OK  ] Stopped dracut pre-udev hook.
>    [  OK  ] Stopped dracut cmdline hook.
>             Starting Setup Virtual Console...
>             Starting Kdump Emergency...
>    [  OK  ] Reached target Initrd Default Target.
>    [  OK  ] Stopped dracut initqueue hook.
>    Failed to start kdump-error-handler.service: Transaction is destructive.
>    See system logs and 'systemctl status kdump-error-handler.service' for
> details.
>    [FAILED] Failed to start Kdump Emergency.
>    See 'systemctl status emergency.service' for details.
>    [DEPEND] Dependency failed for Emergency Mode.
>  
>  This is because in case of root failure, initrd-root-fs.target
>  will trigger systemd emergency target which requires the systemd
>  emergency service actually is kdump-emergency.service, then our
>  kdump-emergency.service starts kdump-error-handler.service with
>  "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
>  replace systemd's with this one under kdump).
>  
>  This will lead to systemd two contradictable jobs queued as an
>  atomic transaction:
>  job 1) the emergency service gets started by initrd-root-fs.target
>  job 2) the emergency service gets stopped due to "systemctl isolate"
>  thereby throwing "Transaction is destructive".
>  
>  In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
>  both kdump-emergency.service and kdump-emergency.target to avoid
>  being isolated, then they can keep going on as expected in case
>  of failures.
>  
>  We add kdump-emergency.target dedicated to kdump the similar way
>  as did for kdump-emergency.service(i.e. will replace systemd's
>  emergency.target with kdump-emergency.target under kdump), and
>  adds "IgnoreOnIsolate=yes" into both of them. 
Is the kdump-emergency.target mandatory to make the isolate working? 

Thanks
Dave

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/28/2017 at 03:50 PM, Dave Young wrote:
>  On 03/27/17 at 12:07pm, Xunlei Pang wrote:
> > We met a problem that the kdump emergency service failed to
> > start when the target dump timeout(we passed "rd.timeout=30"
> > to kdump), it reported "Transaction is destructive" messages:
> >
> >   [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
> >   [DEPEND] Dependency failed for Initrd Root Device.
> >   [ SKIP ] Ordering cycle found, skipping System Initialization
> >   [DEPEND] Dependency failed for /sysroot.
> >   [DEPEND] Dependency failed for Initrd Root File System.
> >   [DEPEND] Dependency failed for Reload Configuration from the Real Root.
> >   [ SKIP ] Ordering cycle found, skipping System Initialization
> >   [ SKIP ] Ordering cycle found, skipping Initrd Default Target
> >   [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
> >   [  OK  ] Reached target Initrd File Systems.
> >   [  OK  ] Stopped dracut pre-udev hook.
> >   [  OK  ] Stopped dracut cmdline hook.
> >            Starting Setup Virtual Console...
> >            Starting Kdump Emergency...
> >   [  OK  ] Reached target Initrd Default Target.
> >   [  OK  ] Stopped dracut initqueue hook.
> >   Failed to start kdump-error-handler.service: Transaction is destructive.
> >   See system logs and 'systemctl status kdump-error-handler.service' for
> details.
> >   [FAILED] Failed to start Kdump Emergency.
> >   See 'systemctl status emergency.service' for details.
> >   [DEPEND] Dependency failed for Emergency Mode.
> >
> > This is because in case of root failure, initrd-root-fs.target
> > will trigger systemd emergency target which requires the systemd
> > emergency service actually is kdump-emergency.service, then our
> > kdump-emergency.service starts kdump-error-handler.service with
> > "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
> > replace systemd's with this one under kdump).
> >
> > This will lead to systemd two contradictable jobs queued as an
> > atomic transaction:
> > job 1) the emergency service gets started by initrd-root-fs.target
> > job 2) the emergency service gets stopped due to "systemctl isolate"
> > thereby throwing "Transaction is destructive".
> >
> > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> > both kdump-emergency.service and kdump-emergency.target to avoid
> > being isolated, then they can keep going on as expected in case
> > of failures.
> >
> > We add kdump-emergency.target dedicated to kdump the similar way
> > as did for kdump-emergency.service(i.e. will replace systemd's
> > emergency.target with kdump-emergency.target under kdump), and
> > adds "IgnoreOnIsolate=yes" into both of them.
>  Is the kdump-emergency.target mandatory to make the isolate working?  
Yes, both kdump-emergency.sevice and kdump-emergency.target need
"IgnoreOnIsolate=yes".

Regards,
Xunlei

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  We met a problem that the kdump emergency service failed to
>  start when the target dump timeout(we passed "rd.timeout=30"
>  to kdump), it reported "Transaction is destructive" messages:
>  
>    [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
>    [DEPEND] Dependency failed for Initrd Root Device.
>    [ SKIP ] Ordering cycle found, skipping System Initialization
>    [DEPEND] Dependency failed for /sysroot.
>    [DEPEND] Dependency failed for Initrd Root File System.
>    [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>    [ SKIP ] Ordering cycle found, skipping System Initialization
>    [ SKIP ] Ordering cycle found, skipping Initrd Default Target
>    [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
>    [  OK  ] Reached target Initrd File Systems.
>    [  OK  ] Stopped dracut pre-udev hook.
>    [  OK  ] Stopped dracut cmdline hook.
>             Starting Setup Virtual Console...
>             Starting Kdump Emergency...
>    [  OK  ] Reached target Initrd Default Target.
>    [  OK  ] Stopped dracut initqueue hook.
>    Failed to start kdump-error-handler.service: Transaction is destructive.
>    See system logs and 'systemctl status kdump-error-handler.service' for
> details.
>    [FAILED] Failed to start Kdump Emergency.
>    See 'systemctl status emergency.service' for details.
>    [DEPEND] Dependency failed for Emergency Mode.
>  
>  This is because in case of root failure, initrd-root-fs.target
>  will trigger systemd emergency target which requires the systemd
>  emergency service actually is kdump-emergency.service, then our
>  kdump-emergency.service starts kdump-error-handler.service with
>  "systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
>  replace systemd's with this one under kdump).
>  
>  This will lead to systemd two contradictable jobs queued as an
>  atomic transaction:
>  job 1) the emergency service gets started by initrd-root-fs.target
>  job 2) the emergency service gets stopped due to "systemctl isolate"
>  thereby throwing "Transaction is destructive".
>  
>  In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
>  both kdump-emergency.service and kdump-emergency.target to avoid
>  being isolated, then they can keep going on as expected in case
>  of failures.
>  
>  We add kdump-emergency.target dedicated to kdump the similar way
>  as did for kdump-emergency.service(i.e. will replace systemd's
>  emergency.target with kdump-emergency.target under kdump), and 
I didn't see emergency has a target, could you tell where I can find it?

> adds "IgnoreOnIsolate=yes" into both of them.
> 
> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> ---
>  dracut-kdump-emergency.service |  1 +
>  dracut-kdump-emergency.target  | 14 ++++++++++++++
>  dracut-module-setup.sh         |  3 ++-
>  kexec-tools.spec               |  2 ++
>  4 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 dracut-kdump-emergency.target
> 
> diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
> index fb764f2..e023284 100644
> --- a/dracut-kdump-emergency.service
> +++ b/dracut-kdump-emergency.service
> @@ -12,6 +12,7 @@
>  [Unit]
>  Description=Kdump Emergency
>  DefaultDependencies=no
> +IgnoreOnIsolate=yes
>  
>  [Service]
>  ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
> diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> new file mode 100644
> index 0000000..a1bb493
> --- /dev/null
> +++ b/dracut-kdump-emergency.target
> @@ -0,0 +1,14 @@
> +#  This file is part of systemd.
> +#
> +#  systemd is free software; you can redistribute it and/or modify it
> +#  under the terms of the GNU Lesser General Public License as published by
> +#  the Free Software Foundation; either version 2.1 of the License, or
> +#  (at your option) any later version.
> +
> +[Unit]
> +Description=Emergency Mode
> +Documentation=man:systemd.special(7)
> +Requires=emergency.service
> +After=emergency.service
> +AllowIsolate=yes
> +IgnoreOnIsolate=yes
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index 1f96bb8..fa4fa2a 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -734,8 +734,9 @@ install() {
>      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
>      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
>      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> -    # Replace existing emergency service
> +    # Replace existing emergency service and emergency target
>      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
>      # Also redirect dracut-emergency to kdump error handler
>      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
>  
> diff --git a/kexec-tools.spec b/kexec-tools.spec
> index 2a176f3..c3359fb 100644
> --- a/kexec-tools.spec
> +++ b/kexec-tools.spec
> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
>  Source104: dracut-kdump-emergency.service
>  Source105: dracut-kdump-error-handler.service
>  Source106: dracut-kdump-capture.service
> +Source107: dracut-kdump-emergency.target
>  
>  Requires(post): systemd-units
>  Requires(preun): systemd-units
> @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
>  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
>  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
>  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
>  
> -- 
> 1.8.3.1
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Pratyush Anand]

On Tuesday 28 March 2017 01:41 PM, Baoquan He wrote:
> > We add kdump-emergency.target dedicated to kdump the similar way
> > as did for kdump-emergency.service(i.e. will replace systemd's
> > emergency.target with kdump-emergency.target under kdump), and
>  I didn't see emergency has a target, could you tell where I can find it?
>  
$ locate emergency.target
/usr/lib/systemd/system/emergency.target

~Pratyush

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/28/17 at 02:21pm, Pratyush Anand wrote:
>  
>  
>  On Tuesday 28 March 2017 01:41 PM, Baoquan He wrote:
>  > > We add kdump-emergency.target dedicated to kdump the similar way
>  > > as did for kdump-emergency.service(i.e. will replace systemd's
>  > > emergency.target with kdump-emergency.target under kdump), and
>  > I didn't see emergency has a target, could you tell where I can find it?
>  > 
>  
>  $ locate emergency.target
>  /usr/lib/systemd/system/emergency.target 
Yes, thanks.

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  This will lead to systemd two contradictable jobs queued as an
>  atomic transaction:
>  job 1) the emergency service gets started by initrd-root-fs.target
>  job 2) the emergency service gets stopped due to "systemctl isolate"
>  thereby throwing "Transaction is destructive".
>  
>  In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
>  both kdump-emergency.service and kdump-emergency.target to avoid
>  being isolated, then they can keep going on as expected in case
>  of failures. 
A small concern. Above paragraph, IgnoreOnIsolate is newly introduced
option, we could make it clearer for later reviewing if forget. How
about writing it like:

In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
kdump-emergency.service and kdump-emergency.target. Service or target
with attribute "IgnoreOnIsolate=yes" won't be stopped by other service
/target being isolated, then they can keep going as expected in case be
triggered by any failure.

Here, not sure if we can use systemd unit instead of service/target. I
feel systemd unit is not appropriate here.

> 
> We add kdump-emergency.target dedicated to kdump the similar way
> as did for kdump-emergency.service(i.e. will replace systemd's
> emergency.target with kdump-emergency.target under kdump), and
> adds "IgnoreOnIsolate=yes" into both of them.
> 
> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> ---
>  dracut-kdump-emergency.service |  1 +
>  dracut-kdump-emergency.target  | 14 ++++++++++++++
>  dracut-module-setup.sh         |  3 ++-
>  kexec-tools.spec               |  2 ++
>  4 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 dracut-kdump-emergency.target
> 
> diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
> index fb764f2..e023284 100644
> --- a/dracut-kdump-emergency.service
> +++ b/dracut-kdump-emergency.service
> @@ -12,6 +12,7 @@
>  [Unit]
>  Description=Kdump Emergency
>  DefaultDependencies=no
> +IgnoreOnIsolate=yes
>  
>  [Service]
>  ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
> diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> new file mode 100644
> index 0000000..a1bb493
> --- /dev/null
> +++ b/dracut-kdump-emergency.target
> @@ -0,0 +1,14 @@
> +#  This file is part of systemd.
> +#
> +#  systemd is free software; you can redistribute it and/or modify it
> +#  under the terms of the GNU Lesser General Public License as published by
> +#  the Free Software Foundation; either version 2.1 of the License, or
> +#  (at your option) any later version.
> +
> +[Unit]
> +Description=Emergency Mode
> +Documentation=man:systemd.special(7)
> +Requires=emergency.service
> +After=emergency.service
> +AllowIsolate=yes
> +IgnoreOnIsolate=yes
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index 1f96bb8..fa4fa2a 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -734,8 +734,9 @@ install() {
>      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
>      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
>      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> -    # Replace existing emergency service
> +    # Replace existing emergency service and emergency target
>      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
>      # Also redirect dracut-emergency to kdump error handler
>      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
>  
> diff --git a/kexec-tools.spec b/kexec-tools.spec
> index 2a176f3..c3359fb 100644
> --- a/kexec-tools.spec
> +++ b/kexec-tools.spec
> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
>  Source104: dracut-kdump-emergency.service
>  Source105: dracut-kdump-error-handler.service
>  Source106: dracut-kdump-capture.service
> +Source107: dracut-kdump-emergency.target
>  
>  Requires(post): systemd-units
>  Requires(preun): systemd-units
> @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
>  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
>  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
>  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
>  
> -- 
> 1.8.3.1
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Xunlei Pang]

On 03/30/2017 at 09:38 AM, Baoquan He wrote:
>  On 03/27/17 at 12:07pm, Xunlei Pang wrote:
> > This will lead to systemd two contradictable jobs queued as an
> > atomic transaction:
> > job 1) the emergency service gets started by initrd-root-fs.target
> > job 2) the emergency service gets stopped due to "systemctl isolate"
> > thereby throwing "Transaction is destructive".
> >
> > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> > both kdump-emergency.service and kdump-emergency.target to avoid
> > being isolated, then they can keep going on as expected in case
> > of failures.
>  A small concern. Above paragraph, IgnoreOnIsolate is newly introduced
>  option, we could make it clearer for later reviewing if forget. How
>  about writing it like:
>
>  In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
>  kdump-emergency.service and kdump-emergency.target. Service or target
>  with attribute "IgnoreOnIsolate=yes" won't be stopped by other service
>  /target being isolated, then they can keep going as expected in case be
>  triggered by any failure.
>
>  Here, not sure if we can use systemd unit instead of service/target. I
>  feel systemd unit is not appropriate here. 
Unit is ok, it's a general concept for service, target, mount, socket, ...

In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
kdump-emergency.service and kdump-emergency.target. Unit with attribute
"IgnoreOnIsolate=yes" won't be stopped when isolating another unit,
they can keep going as expected in case be triggered by any failure.

Regards,
Xunlei

> > We add kdump-emergency.target dedicated to kdump the similar way
> > as did for kdump-emergency.service(i.e. will replace systemd's
> > emergency.target with kdump-emergency.target under kdump), and
> > adds "IgnoreOnIsolate=yes" into both of them.
> >
> > Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> > ---
> >  dracut-kdump-emergency.service |  1 +
> >  dracut-kdump-emergency.target  | 14 ++++++++++++++
> >  dracut-module-setup.sh         |  3 ++-
> >  kexec-tools.spec               |  2 ++
> >  4 files changed, 19 insertions(+), 1 deletion(-)
> >  create mode 100644 dracut-kdump-emergency.target
> >
> > diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service
> > index fb764f2..e023284 100644
> > --- a/dracut-kdump-emergency.service
> > +++ b/dracut-kdump-emergency.service
> > @@ -12,6 +12,7 @@
> >  [Unit]
> >  Description=Kdump Emergency
> >  DefaultDependencies=no
> > +IgnoreOnIsolate=yes
> >  
> >  [Service]
> >  ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service
> > diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> > new file mode 100644
> > index 0000000..a1bb493
> > --- /dev/null
> > +++ b/dracut-kdump-emergency.target
> > @@ -0,0 +1,14 @@
> > +#  This file is part of systemd.
> > +#
> > +#  systemd is free software; you can redistribute it and/or modify it
> > +#  under the terms of the GNU Lesser General Public License as published by
> > +#  the Free Software Foundation; either version 2.1 of the License, or
> > +#  (at your option) any later version.
> > +
> > +[Unit]
> > +Description=Emergency Mode
> > +Documentation=man:systemd.special(7)
> > +Requires=emergency.service
> > +After=emergency.service
> > +AllowIsolate=yes
> > +IgnoreOnIsolate=yes
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index 1f96bb8..fa4fa2a 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -734,8 +734,9 @@ install() {
> >      ln_r "$systemdsystemunitdir/kdump-capture.service"
> "$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> >      inst "$moddir/kdump-error-handler.sh"
> "/usr/bin/kdump-error-handler.sh"
> >      inst "$moddir/kdump-error-handler.service"
> "$systemdsystemunitdir/kdump-error-handler.service"
> > -    # Replace existing emergency service
> > +    # Replace existing emergency service and emergency target
> >      cp "$moddir/kdump-emergency.service"
> "$initdir/$systemdsystemunitdir/emergency.service"
> > +    cp "$moddir/kdump-emergency.target"
> "$initdir/$systemdsystemunitdir/emergency.target"
> >      # Also redirect dracut-emergency to kdump error handler
> >      ln_r "$systemdsystemunitdir/emergency.service"
> "$systemdsystemunitdir/dracut-emergency.service"
> >  
> > diff --git a/kexec-tools.spec b/kexec-tools.spec
> > index 2a176f3..c3359fb 100644
> > --- a/kexec-tools.spec
> > +++ b/kexec-tools.spec
> > @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> >  Source104: dracut-kdump-emergency.service
> >  Source105: dracut-kdump-error-handler.service
> >  Source106: dracut-kdump-capture.service
> > +Source107: dracut-kdump-emergency.target
> >  
> >  Requires(post): systemd-units
> >  Requires(preun): systemd-units
> > @@ -197,6 +198,7 @@ cp %{SOURCE103}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> >  cp %{SOURCE104}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE104}}
> >  cp %{SOURCE105}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE105}}
> >  cp %{SOURCE106}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE106}}
> > +cp %{SOURCE107}
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE107}}
> >  chmod 755
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE100}}
> >  chmod 755
> $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
> %{SOURCE101}}
> >  
> > -- 
> > 1.8.3.1
> > _______________________________________________
> > kexec mailing list -- kexec(a)lists.fedoraproject.org
> > To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Baoquan He]

On 03/30/17 at 09:49am, Xunlei Pang wrote:
>  On 03/30/2017 at 09:38 AM, Baoquan He wrote:
>  > On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  >> This will lead to systemd two contradictable jobs queued as an
>  >> atomic transaction:
>  >> job 1) the emergency service gets started by initrd-root-fs.target
>  >> job 2) the emergency service gets stopped due to "systemctl isolate"
>  >> thereby throwing "Transaction is destructive".
>  >>
>  >> In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
>  >> both kdump-emergency.service and kdump-emergency.target to avoid
>  >> being isolated, then they can keep going on as expected in case
>  >> of failures.
>  > A small concern. Above paragraph, IgnoreOnIsolate is newly introduced
>  > option, we could make it clearer for later reviewing if forget. How
>  > about writing it like:
>  >
>  > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
>  > kdump-emergency.service and kdump-emergency.target. Service or target
>  > with attribute "IgnoreOnIsolate=yes" won't be stopped by other
> service
>  > /target being isolated, then they can keep going as expected in case be
>  > triggered by any failure.
>  >
>  > Here, not sure if we can use systemd unit instead of service/target. I
>  > feel systemd unit is not appropriate here.
>  
>  Unit is ok, it's a general concept for service, target, mount, socket, ...
>  
>  In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
>  kdump-emergency.service and kdump-emergency.target. Unit with attribute
>  "IgnoreOnIsolate=yes" won't be stopped when isolating another unit,
>  they can keep going as expected in case be triggered by any failure. 
Yeah, agree. Better say systemd unit here. Otherwise this looks good to
me. Dave could replace with these directly when merge since He and
Pratyush have acked.

> 
> >> We add kdump-emergency.target dedicated to kdump the similar way
> >> as did for kdump-emergency.service(i.e. will replace systemd's
> >> emergency.target with kdump-emergency.target under kdump), and
> >> adds "IgnoreOnIsolate=yes" into both of them.
> >>
> >> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> >> ---
> >>  dracut-kdump-emergency.service |  1 +
> >>  dracut-kdump-emergency.target  | 14 ++++++++++++++
> >>  dracut-module-setup.sh         |  3 ++-
> >>  kexec-tools.spec               |  2 ++
> >>  4 files changed, 19 insertions(+), 1 deletion(-)
> >>  create mode 100644 dracut-kdump-emergency.target
> >>
> >> diff --git a/dracut-kdump-emergency.service
b/dracut-kdump-emergency.service
> >> index fb764f2..e023284 100644
> >> --- a/dracut-kdump-emergency.service
> >> +++ b/dracut-kdump-emergency.service
> >> @@ -12,6 +12,7 @@
> >>  [Unit]
> >>  Description=Kdump Emergency
> >>  DefaultDependencies=no
> >> +IgnoreOnIsolate=yes
> >>  
> >>  [Service]
> >>  ExecStart=/usr/bin/systemctl --no-block isolate
kdump-error-handler.service
> >> diff --git a/dracut-kdump-emergency.target b/dracut-kdump-emergency.target
> >> new file mode 100644
> >> index 0000000..a1bb493
> >> --- /dev/null
> >> +++ b/dracut-kdump-emergency.target
> >> @@ -0,0 +1,14 @@
> >> +#  This file is part of systemd.
> >> +#
> >> +#  systemd is free software; you can redistribute it and/or modify it
> >> +#  under the terms of the GNU Lesser General Public License as published
by
> >> +#  the Free Software Foundation; either version 2.1 of the License, or
> >> +#  (at your option) any later version.
> >> +
> >> +[Unit]
> >> +Description=Emergency Mode
> >> +Documentation=man:systemd.special(7)
> >> +Requires=emergency.service
> >> +After=emergency.service
> >> +AllowIsolate=yes
> >> +IgnoreOnIsolate=yes
> >> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> >> index 1f96bb8..fa4fa2a 100755
> >> --- a/dracut-module-setup.sh
> >> +++ b/dracut-module-setup.sh
> >> @@ -734,8 +734,9 @@ install() {
> >>      ln_r "$systemdsystemunitdir/kdump-capture.service"
"$systemdsystemunitdir/initrd.target.wants/kdump-capture.service"
> >>      inst "$moddir/kdump-error-handler.sh"
"/usr/bin/kdump-error-handler.sh"
> >>      inst "$moddir/kdump-error-handler.service"
"$systemdsystemunitdir/kdump-error-handler.service"
> >> -    # Replace existing emergency service
> >> +    # Replace existing emergency service and emergency target
> >>      cp "$moddir/kdump-emergency.service"
"$initdir/$systemdsystemunitdir/emergency.service"
> >> +    cp "$moddir/kdump-emergency.target"
"$initdir/$systemdsystemunitdir/emergency.target"
> >>      # Also redirect dracut-emergency to kdump error handler
> >>      ln_r "$systemdsystemunitdir/emergency.service"
"$systemdsystemunitdir/dracut-emergency.service"
> >>  
> >> diff --git a/kexec-tools.spec b/kexec-tools.spec
> >> index 2a176f3..c3359fb 100644
> >> --- a/kexec-tools.spec
> >> +++ b/kexec-tools.spec
> >> @@ -41,6 +41,7 @@ Source103: dracut-kdump-error-handler.sh
> >>  Source104: dracut-kdump-emergency.service
> >>  Source105: dracut-kdump-error-handler.service
> >>  Source106: dracut-kdump-capture.service
> >> +Source107: dracut-kdump-emergency.target
> >>  
> >>  Requires(post): systemd-units
> >>  Requires(preun): systemd-units
> >> @@ -197,6 +198,7 @@ cp %{SOURCE103}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb
> >>  cp %{SOURCE104}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE104}}
> >>  cp %{SOURCE105}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE105}}
> >>  cp %{SOURCE106}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE106}}
> >> +cp %{SOURCE107}
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE107}}
> >>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE100}}
> >>  chmod 755
$RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix
%{SOURCE101}}
> >>  
> >> -- 
> >> 1.8.3.1
> >> _______________________________________________
> >> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
>

[PATCH 2/2] kdump-emergency: fix "Transaction is destructive" emergency failure

[Dave Young]

On 03/30/17 at 09:53am, Baoquan He wrote:
>  On 03/30/17 at 09:49am, Xunlei Pang wrote:
>  > On 03/30/2017 at 09:38 AM, Baoquan He wrote:
>  > > On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  > >> This will lead to systemd two contradictable jobs queued as an
>  > >> atomic transaction:
>  > >> job 1) the emergency service gets started by initrd-root-fs.target
>  > >> job 2) the emergency service gets stopped due to "systemctl
> isolate"
>  > >> thereby throwing "Transaction is destructive".
>  > >>
>  > >> In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
>  > >> both kdump-emergency.service and kdump-emergency.target to avoid
>  > >> being isolated, then they can keep going on as expected in case
>  > >> of failures.
>  > > A small concern. Above paragraph, IgnoreOnIsolate is newly introduced
>  > > option, we could make it clearer for later reviewing if forget. How
>  > > about writing it like:
>  > >
>  > > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
>  > > kdump-emergency.service and kdump-emergency.target. Service or target
>  > > with attribute "IgnoreOnIsolate=yes" won't be stopped by other
> service
>  > > /target being isolated, then they can keep going as expected in case be
>  > > triggered by any failure.
>  > >
>  > > Here, not sure if we can use systemd unit instead of service/target. I
>  > > feel systemd unit is not appropriate here.
>  > 
>  > Unit is ok, it's a general concept for service, target, mount, socket, ...
>  > 
>  > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
>  > kdump-emergency.service and kdump-emergency.target. Unit with attribute
>  > "IgnoreOnIsolate=yes" won't be stopped when isolating another unit,
>  > they can keep going as expected in case be triggered by any failure.
>  
>  Yeah, agree. Better say systemd unit here. Otherwise this looks good to
>  me. Dave could replace with these directly when merge since He and
>  Pratyush have acked. 
Added in the commit..

Thanks
Dave

[Dave Young]

On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  I found this problem when debugging "Transaction is
> destructive"
>  (see the following patch) issue using nfs, in the case that nfs
>  is mounted implicitly to the save path other than explicitly
>  using the "nfs" directive in /etc/kdump.conf, "is_nfs_dump_target"
>  will return false, so this nfs mount will be added "x-initrd.mount"
>  option wrongly.
>  
>  It affects the systemd service behaviours when emergency failure
>  happens as the code comment described.
>  
>  To fix it, we use "is_fs_type_nfs $_fstype" instead.
>  
>  Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
>  ---
>   mkdumprd | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>  
>  diff --git a/mkdumprd b/mkdumprd
>  index f30d9c2..f1bac01 100644
>  --- a/mkdumprd
>  +++ b/mkdumprd
>  @@ -120,7 +120,7 @@ to_mount() {
>       # If remote mount fails, dracut-initqueue will still start and once
>       # dracut-initqueue finishes, kdump service will start. Because remote mount
>       # failed, kdump service will fail and it will lead to kdump error handler.
>  -    if ! is_nfs_dump_target; then
>  +    if ! is_fs_type_nfs $_fstype; then
>          _options="$_options,x-initrd.mount"
>       fi
>       _mntopts="$_target $_fstype $_options"
>  -- 
>  1.8.3.1
>  _______________________________________________
>  kexec mailing list -- kexec(a)lists.fedoraproject.org
>  To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org 
Acked-by: Dave Young <dyoung(a)redhat.com&gt;

Thanks
Dave

[Dave Young]

On 03/28/17 at 03:48pm, Dave Young wrote:
>  On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  > I found this problem when debugging "Transaction is destructive"
>  > (see the following patch) issue using nfs, in the case that nfs
>  > is mounted implicitly to the save path other than explicitly
>  > using the "nfs" directive in /etc/kdump.conf,
> "is_nfs_dump_target"
>  > will return false, so this nfs mount will be added "x-initrd.mount"
>  > option wrongly.
>  > 
>  > It affects the systemd service behaviours when emergency failure
>  > happens as the code comment described.
>  > 
>  > To fix it, we use "is_fs_type_nfs $_fstype" instead.
>  > 
>  > Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
>  > ---
>  >  mkdumprd | 2 +-
>  >  1 file changed, 1 insertion(+), 1 deletion(-)
>  > 
>  > diff --git a/mkdumprd b/mkdumprd
>  > index f30d9c2..f1bac01 100644
>  > --- a/mkdumprd
>  > +++ b/mkdumprd
>  > @@ -120,7 +120,7 @@ to_mount() {
>  >      # If remote mount fails, dracut-initqueue will still start and once
>  >      # dracut-initqueue finishes, kdump service will start. Because remote mount
>  >      # failed, kdump service will fail and it will lead to kdump error handler.
>  > -    if ! is_nfs_dump_target; then
>  > +    if ! is_fs_type_nfs $_fstype; then
>  >         _options="$_options,x-initrd.mount"
>  >      fi
>  >      _mntopts="$_target $_fstype $_options"
>  > -- 
>  > 1.8.3.1
>  > _______________________________________________
>  > kexec mailing list -- kexec(a)lists.fedoraproject.org
>  > To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
>  
>  Acked-by: Dave Young <dyoung(a)redhat.com&gt; 
Per discussion in irc. let's defer this one since during your testing
kdump works well without appending x-initrd.mount. Let's do more test
and work on it after understanding why later..

> 
> Thanks
> Dave

[Xunlei Pang]

On 03/29/2017 at 02:29 PM, Dave Young wrote:
>  On 03/28/17 at 03:48pm, Dave Young wrote:
> > On 03/27/17 at 12:07pm, Xunlei Pang wrote:
> >> I found this problem when debugging "Transaction is destructive"
> >> (see the following patch) issue using nfs, in the case that nfs
> >> is mounted implicitly to the save path other than explicitly
> >> using the "nfs" directive in /etc/kdump.conf,
> "is_nfs_dump_target"
> >> will return false, so this nfs mount will be added "x-initrd.mount"
> >> option wrongly.
> >>
> >> It affects the systemd service behaviours when emergency failure
> >> happens as the code comment described.
> >>
> >> To fix it, we use "is_fs_type_nfs $_fstype" instead.
> >>
> >> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> >> ---
> >>  mkdumprd | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/mkdumprd b/mkdumprd
> >> index f30d9c2..f1bac01 100644
> >> --- a/mkdumprd
> >> +++ b/mkdumprd
> >> @@ -120,7 +120,7 @@ to_mount() {
> >>      # If remote mount fails, dracut-initqueue will still start and once
> >>      # dracut-initqueue finishes, kdump service will start. Because remote mount
> >>      # failed, kdump service will fail and it will lead to kdump error handler.
> >> -    if ! is_nfs_dump_target; then
> >> +    if ! is_fs_type_nfs $_fstype; then
> >>         _options="$_options,x-initrd.mount"
> >>      fi
> >>      _mntopts="$_target $_fstype $_options"
> >> -- 
> >> 1.8.3.1
> >> _______________________________________________
> >> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> > Acked-by: Dave Young <dyoung(a)redhat.com&gt;
>  Per discussion in irc. let's defer this one since during your testing
>  kdump works well without appending x-initrd.mount. Let's do more test
>  and work on it after understanding why later.. 
Maybe I made a mistake last time when testing rhel7, there is some difference between
rhel7 and Fedora
in terms of systemd. The difference was introduced by the following systemd fstab
generator commit, that's
why "x-initrd.mount" makes no difference on Fedora which uses a newer systemd
including this commit:

commit ce3f6d82b003f365f718f24e48f55b8a0372b924
Author: nmartensen <nis.martensen(a)web.de&gt;
Date:   Fri Jan 15 07:55:25 2016 +0100

    fstab-generator: remove bogus condition
   
    The sysroot mount is already taken care of by the add_sysroot_mount function. With
this condition left in, we can g
   
    initrd-root-fs.target.requires
    `-- usr.mount -> /run/systemd/generator/usr.mount
   
    in the main system (i.e., not in the initramfs). In the initramfs, the previous
condition already kicks in.

diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 87b8b77..c924b65 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -463,8 +463,6 @@ static int parse_fstab(bool initrd) {
                                                      
"x-systemd.automount\0");
                         if (initrd)
                                 post = SPECIAL_INITRD_FS_TARGET;
-                        else if (mount_in_initrd(me))  // true if with
"x-initrd.mount" option
-                                post = SPECIAL_INITRD_ROOT_FS_TARGET;
                         else if (mount_is_network(me))
                                 post = SPECIAL_REMOTE_FS_TARGET;
                         else

[Baoquan He]

On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  I found this problem when debugging "Transaction is
> destructive"
>  (see the following patch) issue using nfs, in the case that nfs
>  is mounted implicitly to the save path other than explicitly
>  using the "nfs" directive in /etc/kdump.conf, "is_nfs_dump_target"
>  will return false, so this nfs mount will be added "x-initrd.mount"
>  option wrongly.
>  
>  It affects the systemd service behaviours when emergency failure
>  happens as the code comment described.
>  
>  To fix it, we use "is_fs_type_nfs $_fstype" instead.
>  
>  Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
>  ---
>   mkdumprd | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>  
>  diff --git a/mkdumprd b/mkdumprd
>  index f30d9c2..f1bac01 100644
>  --- a/mkdumprd
>  +++ b/mkdumprd
>  @@ -120,7 +120,7 @@ to_mount() {
>       # If remote mount fails, dracut-initqueue will still start and once
>       # dracut-initqueue finishes, kdump service will start. Because remote mount
>       # failed, kdump service will fail and it will lead to kdump error handler.
>  -    if ! is_nfs_dump_target; then
>  +    if ! is_fs_type_nfs $_fstype; then 
This sounds reasonable. But one question comes up, checking fedora git
log, I found commit about this code adding was merged earlier than the
commit de95c74 ("mkdumprd: append "x-initrd.mount" to the mount
options.").

May I assume since commit de95c74 has been added, x-initrd.mount adding
is not needed anymore?

>         _options="$_options,x-initrd.mount"
>      fi
>      _mntopts="$_target $_fstype $_options"
> -- 
> 1.8.3.1
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[Xunlei Pang]

On 03/28/2017 at 04:05 PM, Baoquan He wrote:
>  On 03/27/17 at 12:07pm, Xunlei Pang wrote:
> > I found this problem when debugging "Transaction is destructive"
> > (see the following patch) issue using nfs, in the case that nfs
> > is mounted implicitly to the save path other than explicitly
> > using the "nfs" directive in /etc/kdump.conf,
> "is_nfs_dump_target"
> > will return false, so this nfs mount will be added "x-initrd.mount"
> > option wrongly.
> >
> > It affects the systemd service behaviours when emergency failure
> > happens as the code comment described.
> >
> > To fix it, we use "is_fs_type_nfs $_fstype" instead.
> >
> > Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> > ---
> >  mkdumprd | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mkdumprd b/mkdumprd
> > index f30d9c2..f1bac01 100644
> > --- a/mkdumprd
> > +++ b/mkdumprd
> > @@ -120,7 +120,7 @@ to_mount() {
> >      # If remote mount fails, dracut-initqueue will still start and once
> >      # dracut-initqueue finishes, kdump service will start. Because remote mount
> >      # failed, kdump service will fail and it will lead to kdump error handler.
> > -    if ! is_nfs_dump_target; then
> > +    if ! is_fs_type_nfs $_fstype; then
>  This sounds reasonable. But one question comes up, checking fedora git
>  log, I found commit about this code adding was merged earlier than the
>  commit de95c74 ("mkdumprd: append "x-initrd.mount" to the mount
> options.").
>
>  May I assume since commit de95c74 has been added, x-initrd.mount adding
>  is not needed anymore? 
x-initrd.mount and is_nfs_dump_target judgement are introduced in the same commit
de95c74,
--- a/mkdumprd
+++ b/mkdumprd
@@ -106,6 +106,20 @@ to_mount() {
     _fstype=$(findmnt -k -f -n -r -o FSTYPE $_dev)
     _options=$(findmnt -k -f -n -r -o OPTIONS $_dev)
     _options=${_options/#ro/rw} #mount fs target as rw in 2nd kernel
+    # "x-initrd.mount" mount failure will trigger isolate emergency service
+    # W/o this, systemd won't isolate, thus we won't get to emergency.
+    # This is not applicable to remote fs mount, because if we use
+    # "x-initrd.mount", remote mount will become required by
+    # "initrd-root-fs.target", instead of "remote-fs.target".
That's how it is
+    # handled within systemd internal. We need remote mount to be required
+    # "remote-fs.target", because we need to bring up network before any
remote
+    # mount and "remote-fs.target" can be a checkpoint of that.
+    # If remote mount fails, dracut-initqueue will still start and once
+    # dracut-initqueue finishes, kdump service will start. Because remote mount
+    # failed, kdump service will fail and it will lead to kdump error handler.
+    if ! is_nfs_dump_target; then
+       _options="$_options,x-initrd.mount"
+    fi
     _mntopts="$_target $_fstype $_options"
     #for non-nfs _dev converting to use udev persistent name
     if [ -b "$_source" ]; then

Which code do you mean is earlier than this?

Regards,
Xunlei

> >         _options="$_options,x-initrd.mount"
> >      fi
> >      _mntopts="$_target $_fstype $_options"
> > -- 
> > 1.8.3.1
> > _______________________________________________
> > kexec mailing list -- kexec(a)lists.fedoraproject.org
> > To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[Baoquan He]

On 03/28/17 at 05:03pm, Xunlei Pang wrote:
>  On 03/28/2017 at 04:05 PM, Baoquan He wrote:
>  > On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>  >> I found this problem when debugging "Transaction is destructive"
>  >> (see the following patch) issue using nfs, in the case that nfs
>  >> is mounted implicitly to the save path other than explicitly
>  >> using the "nfs" directive in /etc/kdump.conf,
> "is_nfs_dump_target"
>  >> will return false, so this nfs mount will be added "x-initrd.mount"
>  >> option wrongly.
>  >>
>  >> It affects the systemd service behaviours when emergency failure
>  >> happens as the code comment described.
>  >>
>  >> To fix it, we use "is_fs_type_nfs $_fstype" instead.
>  >>
>  >> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
>  >> ---
>  >>  mkdumprd | 2 +-
>  >>  1 file changed, 1 insertion(+), 1 deletion(-)
>  >>
>  >> diff --git a/mkdumprd b/mkdumprd
>  >> index f30d9c2..f1bac01 100644
>  >> --- a/mkdumprd
>  >> +++ b/mkdumprd
>  >> @@ -120,7 +120,7 @@ to_mount() {
>  >>      # If remote mount fails, dracut-initqueue will still start and once
>  >>      # dracut-initqueue finishes, kdump service will start. Because remote
> mount
>  >>      # failed, kdump service will fail and it will lead to kdump error handler.
>  >> -    if ! is_nfs_dump_target; then
>  >> +    if ! is_fs_type_nfs $_fstype; then
>  > This sounds reasonable. But one question comes up, checking fedora git
>  > log, I found commit about this code adding was merged earlier than the
>  > commit de95c74 ("mkdumprd: append "x-initrd.mount" to the mount
> options.").
>  >
>  > May I assume since commit de95c74 has been added, x-initrd.mount adding
>  > is not needed anymore? 
Seems I copied the wrong commit. I mean this one:
002337c Introduce kdump error handling service

> 
> x-initrd.mount and is_nfs_dump_target judgement are introduced in the same commit
de95c74,
> --- a/mkdumprd
> +++ b/mkdumprd
> @@ -106,6 +106,20 @@ to_mount() {
>      _fstype=$(findmnt -k -f -n -r -o FSTYPE $_dev)
>      _options=$(findmnt -k -f -n -r -o OPTIONS $_dev)
>      _options=${_options/#ro/rw} #mount fs target as rw in 2nd kernel
> +    # "x-initrd.mount" mount failure will trigger isolate emergency
service
> +    # W/o this, systemd won't isolate, thus we won't get to emergency.
> +    # This is not applicable to remote fs mount, because if we use
> +    # "x-initrd.mount", remote mount will become required by
> +    # "initrd-root-fs.target", instead of "remote-fs.target".
That's how it is
> +    # handled within systemd internal. We need remote mount to be required
> +    # "remote-fs.target", because we need to bring up network before any
remote
> +    # mount and "remote-fs.target" can be a checkpoint of that.
> +    # If remote mount fails, dracut-initqueue will still start and once
> +    # dracut-initqueue finishes, kdump service will start. Because remote mount
> +    # failed, kdump service will fail and it will lead to kdump error handler.
> +    if ! is_nfs_dump_target; then
> +       _options="$_options,x-initrd.mount"
> +    fi
>      _mntopts="$_target $_fstype $_options"
>      #for non-nfs _dev converting to use udev persistent name
>      if [ -b "$_source" ]; then
> 
> Which code do you mean is earlier than this?
> 
> Regards,
> Xunlei
> 
> >
> >>         _options="$_options,x-initrd.mount"
> >>      fi
> >>      _mntopts="$_target $_fstype $_options"
> >> -- 
> >> 1.8.3.1
> >> _______________________________________________
> >> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
>

[Xunlei Pang]

On 03/28/2017 at 05:08 PM, Baoquan He wrote:
>  On 03/28/17 at 05:03pm, Xunlei Pang wrote:
> > On 03/28/2017 at 04:05 PM, Baoquan He wrote:
> >> On 03/27/17 at 12:07pm, Xunlei Pang wrote:
> >>> I found this problem when debugging "Transaction is destructive"
> >>> (see the following patch) issue using nfs, in the case that nfs
> >>> is mounted implicitly to the save path other than explicitly
> >>> using the "nfs" directive in /etc/kdump.conf,
> "is_nfs_dump_target"
> >>> will return false, so this nfs mount will be added
> "x-initrd.mount"
> >>> option wrongly.
> >>>
> >>> It affects the systemd service behaviours when emergency failure
> >>> happens as the code comment described.
> >>>
> >>> To fix it, we use "is_fs_type_nfs $_fstype" instead.
> >>>
> >>> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com&gt;
> >>> ---
> >>>  mkdumprd | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/mkdumprd b/mkdumprd
> >>> index f30d9c2..f1bac01 100644
> >>> --- a/mkdumprd
> >>> +++ b/mkdumprd
> >>> @@ -120,7 +120,7 @@ to_mount() {
> >>>      # If remote mount fails, dracut-initqueue will still start and once
> >>>      # dracut-initqueue finishes, kdump service will start. Because remote
> mount
> >>>      # failed, kdump service will fail and it will lead to kdump error
> handler.
> >>> -    if ! is_nfs_dump_target; then
> >>> +    if ! is_fs_type_nfs $_fstype; then
> >> This sounds reasonable. But one question comes up, checking fedora git
> >> log, I found commit about this code adding was merged earlier than the
> >> commit de95c74 ("mkdumprd: append "x-initrd.mount" to the mount
> options.").
> >>
> >> May I assume since commit de95c74 has been added, x-initrd.mount adding
> >> is not needed anymore?
>  Seems I copied the wrong commit. I mean this one:
>  002337c Introduce kdump error handling service 
They should be different issues, this one is related to local-fs.target or
remote-fs.target,
according to the comments, if we add x-initrd.mount, it will be regarded as
local-fs.target
related other than remote-fs.target. Systemd handles the two targets in different ways.

Anyway, for nfs dumping using "nfs" directive or just mounted to the save path
should
make no difference.

Regards,
Xunlei

> > x-initrd.mount and is_nfs_dump_target judgement are introduced in the same commit
> de95c74,
> > --- a/mkdumprd
> > +++ b/mkdumprd
> > @@ -106,6 +106,20 @@ to_mount() {
> >      _fstype=$(findmnt -k -f -n -r -o FSTYPE $_dev)
> >      _options=$(findmnt -k -f -n -r -o OPTIONS $_dev)
> >      _options=${_options/#ro/rw} #mount fs target as rw in 2nd kernel
> > +    # "x-initrd.mount" mount failure will trigger isolate emergency
> service
> > +    # W/o this, systemd won't isolate, thus we won't get to emergency.
> > +    # This is not applicable to remote fs mount, because if we use
> > +    # "x-initrd.mount", remote mount will become required by
> > +    # "initrd-root-fs.target", instead of "remote-fs.target".
> That's how it is
> > +    # handled within systemd internal. We need remote mount to be required
> > +    # "remote-fs.target", because we need to bring up network before any
> remote
> > +    # mount and "remote-fs.target" can be a checkpoint of that.
> > +    # If remote mount fails, dracut-initqueue will still start and once
> > +    # dracut-initqueue finishes, kdump service will start. Because remote mount
> > +    # failed, kdump service will fail and it will lead to kdump error handler.
> > +    if ! is_nfs_dump_target; then
> > +       _options="$_options,x-initrd.mount"
> > +    fi
> >      _mntopts="$_target $_fstype $_options"
> >      #for non-nfs _dev converting to use udev persistent name
> >      if [ -b "$_source" ]; then
> >
> > Which code do you mean is earlier than this?
> >
> > Regards,
> > Xunlei
> >
> >>>         _options="$_options,x-initrd.mount"
> >>>      fi
> >>>      _mntopts="$_target $_fstype $_options"
> >>> -- 
> >>> 1.8.3.1
> >>> _______________________________________________
> >>> kexec mailing list -- kexec(a)lists.fedoraproject.org
> >>> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org

[Baoquan He]

On 03/28/17 at 05:22pm, Xunlei Pang wrote:
>  On 03/28/2017 at 05:08 PM, Baoquan He wrote:
>  > On 03/28/17 at 05:03pm, Xunlei Pang wrote:
>  >> On 03/28/2017 at 04:05 PM, Baoquan He wrote:
>  >>>> @@ -120,7 +120,7 @@ to_mount() {
>  >>>>      # If remote mount fails, dracut-initqueue will still start and
> once
>  >>>>      # dracut-initqueue finishes, kdump service will start. Because
> remote mount
>  >>>>      # failed, kdump service will fail and it will lead to kdump error
> handler.
>  >>>> -    if ! is_nfs_dump_target; then
>  >>>> +    if ! is_fs_type_nfs $_fstype; then
>  >>> This sounds reasonable. But one question comes up, checking fedora git
>  >>> log, I found commit about this code adding was merged earlier than the
>  >>> commit de95c74 ("mkdumprd: append "x-initrd.mount" to the
> mount options.").
>  >>>
>  >>> May I assume since commit de95c74 has been added, x-initrd.mount adding
>  >>> is not needed anymore?
>  > Seems I copied the wrong commit. I mean this one:
>  > 002337c Introduce kdump error handling service
>  
>  They should be different issues, this one is related to local-fs.target or
> remote-fs.target,
>  according to the comments, if we add x-initrd.mount, it will be regarded as
> local-fs.target
>  related other than remote-fs.target. Systemd handles the two targets in different ways.
See this paragraph in git log. Add x-initrd.mount just because emergency
service is triggered in non isolate mode, at that time kdump isolate
service has not been added yet, I believe. So with kdump isolate service
added, any mount failure will trigger isolate kdump error handler, does
it really have chance to care if it's x-initrd.mount added or not?

Now when mount in /etc/fstab fails, systemd would not consider it as
critical and it would continue to boot. In fact, emergency service is
triggered, but not in a isolation mode, and it results in the emergency
service getting shutdown at some point later of the boot process. We
need isolation otherwise we won't see any emergency service.


> 
> Anyway, for nfs dumping using "nfs" directive or just mounted to the save
path should
> make no difference.

[Xunlei Pang]

On 03/28/2017 at 05:55 PM, Baoquan He wrote:
>  On 03/28/17 at 05:22pm, Xunlei Pang wrote:
> > On 03/28/2017 at 05:08 PM, Baoquan He wrote:
> >> On 03/28/17 at 05:03pm, Xunlei Pang wrote:
> >>> On 03/28/2017 at 04:05 PM, Baoquan He wrote:
> >>>>> @@ -120,7 +120,7 @@ to_mount() {
> >>>>>      # If remote mount fails, dracut-initqueue will still start and
> once
> >>>>>      # dracut-initqueue finishes, kdump service will start. Because
> remote mount
> >>>>>      # failed, kdump service will fail and it will lead to kdump
> error handler.
> >>>>> -    if ! is_nfs_dump_target; then
> >>>>> +    if ! is_fs_type_nfs $_fstype; then
> >>>> This sounds reasonable. But one question comes up, checking fedora git
> >>>> log, I found commit about this code adding was merged earlier than the
From the fedora git log:
    commit 002337c6715e442f306b87b92340bef15c4420ac
     Author: WANG Chao <chaowang(a)redhat.com&gt;
     Date:   Thu May 8 19:37:15 2014 +0800

        Introduce kdump error handling service

     commit de95c74a76aa515f8e1baf5e5decdefd8ec4a81b
     Author: WANG Chao <chaowang(a)redhat.com&gt;
     Date:   Mon Jun 16 16:57:21 2014 +0800

        mkdumprd: append "x-initrd.mount" to the mount options.

So, "x-initrd.mount" change is after "kdump error handling service".

> >>>> commit de95c74 ("mkdumprd: append
> "x-initrd.mount" to the mount options.").
> >>>>
> >>>> May I assume since commit de95c74 has been added, x-initrd.mount adding
> >>>> is not needed anymore?
> >> Seems I copied the wrong commit. I mean this one:
> >> 002337c Introduce kdump error handling service
> > They should be different issues, this one is related to local-fs.target or
> remote-fs.target,
> > according to the comments, if we add x-initrd.mount, it will be regarded as
> local-fs.target
> > related other than remote-fs.target. Systemd handles the two targets in different
> ways.
>  See this paragraph in git log. Add x-initrd.mount just because emergency
>  service is triggered in non isolate mode, at that time kdump isolate
>  service has not been added yet, I believe. So with kdump isolate service
>  added, any mount failure will trigger isolate kdump error handler, does
>  it really have chance to care if it's x-initrd.mount added or not?
>
>  Now when mount in /etc/fstab fails, systemd would not consider it as
>  critical and it would continue to boot. In fact, emergency service is
>  triggered, but not in a isolation mode, and it results in the emergency
>  service getting shutdown at some point later of the boot process. We
>  need isolation otherwise we won't see any emergency service. 
Yes, I got your point this time. But things have changed until now, for example,
the changelog says "From systemd unit point of view,
"initrd-root-fs.target" has
OnFailureIsolate=yes, but "local-fs.target" doesn't", but on the
current Fedora,
both of them haven't.

Regards,
Xunlei

> > Anyway, for nfs dumping using "nfs" directive or just mounted to the save
> path should
> > make no difference.

[Baoquan He]

On 03/28/17 at 06:33pm, Xunlei Pang wrote:
>  On 03/28/2017 at 05:55 PM, Baoquan He wrote:
>  > On 03/28/17 at 05:22pm, Xunlei Pang wrote:
>  >> On 03/28/2017 at 05:08 PM, Baoquan He wrote:
>  >>> On 03/28/17 at 05:03pm, Xunlei Pang wrote:
>  >>>> On 03/28/2017 at 04:05 PM, Baoquan He wrote:
>  >>>>>> @@ -120,7 +120,7 @@ to_mount() {
>  >>>>>>      # If remote mount fails, dracut-initqueue will still start
> and once
>  >>>>>>      # dracut-initqueue finishes, kdump service will start.
> Because remote mount
>  >>>>>>      # failed, kdump service will fail and it will lead to kdump
> error handler.
>  >>>>>> -    if ! is_nfs_dump_target; then
>  >>>>>> +    if ! is_fs_type_nfs $_fstype; then
>  >>>>> This sounds reasonable. But one question comes up, checking fedora
> git
>  >>>>> log, I found commit about this code adding was merged earlier than
> the
>  
>  From the fedora git log:
>      commit 002337c6715e442f306b87b92340bef15c4420ac
>       Author: WANG Chao <chaowang(a)redhat.com&gt;
>       Date:   Thu May 8 19:37:15 2014 +0800
>  
>          Introduce kdump error handling service
>  
>       commit de95c74a76aa515f8e1baf5e5decdefd8ec4a81b
>       Author: WANG Chao <chaowang(a)redhat.com&gt;
>       Date:   Mon Jun 16 16:57:21 2014 +0800
>  
>          mkdumprd: append "x-initrd.mount" to the mount options. 
We usually don't respect the commit time since it's from posted patch,
instead the commit order need be concerned since that is when patch is
merged and the dependency order.

>

[Xunlei Pang]

On 03/28/2017 at 05:55 PM, Baoquan He wrote:
>  On 03/28/17 at 05:22pm, Xunlei Pang wrote:
> > On 03/28/2017 at 05:08 PM, Baoquan He wrote:
> >> On 03/28/17 at 05:03pm, Xunlei Pang wrote:
> >>> On 03/28/2017 at 04:05 PM, Baoquan He wrote:
> >>>>> @@ -120,7 +120,7 @@ to_mount() {
> >>>>>      # If remote mount fails, dracut-initqueue will still start and
> once
> >>>>>      # dracut-initqueue finishes, kdump service will start. Because
> remote mount
> >>>>>      # failed, kdump service will fail and it will lead to kdump
> error handler.
> >>>>> -    if ! is_nfs_dump_target; then
> >>>>> +    if ! is_fs_type_nfs $_fstype; then
> >>>> This sounds reasonable. But one question comes up, checking fedora git
> >>>> log, I found commit about this code adding was merged earlier than the
> >>>> commit de95c74 ("mkdumprd: append "x-initrd.mount" to the
> mount options.").
> >>>>
> >>>> May I assume since commit de95c74 has been added, x-initrd.mount adding
> >>>> is not needed anymore?
> >> Seems I copied the wrong commit. I mean this one:
> >> 002337c Introduce kdump error handling service
> > They should be different issues, this one is related to local-fs.target or
> remote-fs.target,
> > according to the comments, if we add x-initrd.mount, it will be regarded as
> local-fs.target
> > related other than remote-fs.target. Systemd handles the two targets in different
> ways.
>  See this paragraph in git log. Add x-initrd.mount just because emergency
>  service is triggered in non isolate mode, at that time kdump isolate
>  service has not been added yet, I believe. So with kdump isolate service
>  added, any mount failure will trigger isolate kdump error handler, does
>  it really have chance to care if it's x-initrd.mount added or not?
>
>  Now when mount in /etc/fstab fails, systemd would not consider it as
>  critical and it would continue to boot. In fact, emergency service is
>  triggered, but not in a isolation mode, and it results in the emergency
>  service getting shutdown at some point later of the boot process. We
>  need isolation otherwise we won't see any emergency service.
>  
Hi Baoquan,

I think you are right.

The changelog of commit de95c74a7 ('mkdumprd: append "x-initrd.mount" to the
mount options.') 
is misleading at least for now, it may be true when the patch was drafting.

After reading the system code(also confirm to my test results), the current behaviour of
systemd fstab generator is:
1) for "root=X" in the cmdline, it will generate sysroot.mount unit required by
initrd-root-fs.target
2) for mountinfo in /etc/fstab, for non-network mounts, it will generate mount units
required by local-fs.target
3) for mountinfo in /etc/fstab, for network mounts, it will generate mount units required
by remote-fs.target
4) for mountinfo in /sysroot/etc/fstab with "x-initrd.mount" option, it will
generate mount units required by initrd-fs.target

IOW, x-initrd.mount in local(initramfs) /etc/fstab has no effect on the type of required
target.

Regards,
Xunlei

> > Anyway, for nfs dumping using "nfs" directive or just
> mounted to the save path should
> > make no difference.