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@redhat.com --- 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"
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@redhat.com --- 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}}
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@redhat.com
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}}
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
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
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
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:/#
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
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@redhat.com
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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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.
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
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
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
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:
- In case of failure, kdump-capture.service will still be started by initrd.target, finally we will trigger kdump emergency shell twice.
- 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.
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:
- In case of failure, kdump-capture.service will still be started by initrd.target, finally we will trigger kdump emergency shell twice.
- 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
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
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
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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
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.
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
Acked-by: Dave Young dyoung@redhat.com
Thanks Dave
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
Acked-by: Dave Young dyoung@redhat.com
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
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
Acked-by: Dave Young dyoung@redhat.com
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@web.de 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
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@redhat.com
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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.
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@redhat.com Date: Thu May 8 19:37:15 2014 +0800
Introduce kdump error handling service
commit de95c74a76aa515f8e1baf5e5decdefd8ec4a81b Author: WANG Chao chaowang@redhat.com 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.
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@redhat.com Date: Thu May 8 19:37:15 2014 +0800
Introduce kdump error handling service commit de95c74a76aa515f8e1baf5e5decdefd8ec4a81b Author: WANG Chao <chaowang@redhat.com> 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.
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.
-
Baoquan He -
Dave Young -
Pratyush Anand -
Xunlei Pang -
Xunlei Pang