Currently kdump use some wrapper around dracut emergency service and emergency shell, this have many problems:
- If dracut-initqueue failed back to emergency mode due to timeout, and faiure action is set to dump_to_rootfs, kdump will try start initqueue again, lead to double timeout error. - Dracut's emergency shell have many builtin actions, like perform dracut emergency_action, ask for root password, generate rdsosreport etc.
This series remove the emergency wrapper, and use a standalone kdump emergency shell. Kdump will always perform final_action after kdump shell, so simplified version works fine.
Kairui Song (3): Don's try to restart dracut-initqueue if it's already there Remove the kdump error handler isolation wrapper Use a customized emergency shell
dracut-kdump-emergency.service | 25 +++++++++---------- dracut-kdump-error-handler.service | 33 ------------------------ dracut-module-setup.sh | 1 - kdump-lib-initramfs.sh | 40 +++++++++++++++++++++++++----- kexec-tools.spec | 2 -- 5 files changed, 46 insertions(+), 55 deletions(-) delete mode 100644 dracut-kdump-error-handler.service
This reverts commit 7f1f8f229f546818a891400ac7961e485dcd6f3c again. Previous, kdump's dump_to_rootfs tried to detect if initqueue is running and don't start it if it's already running or failed.
But dump_to_rootfs will run after systemd isolate to emergency target, so previous service status are lost, and the detect is invalid always return false.
But now we can remove the isolate wrapper in following commitsa, this detection will be valid and helpful again.
Signed-off-by: Kairui Song kasong@redhat.com --- kdump-lib-initramfs.sh | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 86065be..7198db1 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -216,8 +216,11 @@ save_opalcore_fs() { dump_to_rootfs() {
- dinfo "Trying to bring up rootfs device" - systemctl start dracut-initqueue + if ! systemctl is-active dracut-initqueue || systemctl is-failed dracut-initqueue; then + dinfo "Trying to bring up initqueue for rootfs mount" + systemctl start dracut-initqueue + fi + dinfo "Waiting for rootfs mount, will timeout after 90 seconds" systemctl start sysroot.mount
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
Also remove the invalid header comments in service file, the service is not part of systemd code. And sync the service spec with dracut.
Signed-off-by: Kairui Song kasong@redhat.com --- dracut-kdump-emergency.service | 25 +++++++++++----------- dracut-kdump-error-handler.service | 33 ------------------------------ dracut-module-setup.sh | 1 - kexec-tools.spec | 2 -- 4 files changed, 12 insertions(+), 49 deletions(-) delete mode 100644 dracut-kdump-error-handler.service
diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service index e023284..f2f6fad 100644 --- a/dracut-kdump-emergency.service +++ b/dracut-kdump-emergency.service @@ -1,27 +1,26 @@ -# 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. - -# This service will be placed in kdump initramfs and replace both the systemd -# emergency service and dracut emergency shell. IOW, any emergency will be -# kick this service and in turn isolating to kdump error handler. +# This service will run the real kdump error handler code. Executing the +# failure action configured in kdump.conf
[Unit] -Description=Kdump Emergency +Description=Kdump Error Handler DefaultDependencies=no -IgnoreOnIsolate=yes +After=systemd-vconsole-setup.service +Wants=systemd-vconsole-setup.service
[Service] -ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service +Environment=HOME=/ +Environment=DRACUT_SYSTEMD=1 +Environment=NEWROOT=/sysroot +WorkingDirectory=/ +ExecStart=/bin/kdump-error-handler.sh +ExecStopPost=-/bin/rm -f -- /.console_lock Type=oneshot StandardInput=tty-force StandardOutput=inherit StandardError=inherit KillMode=process IgnoreSIGPIPE=no +TasksMax=infinity
# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash # terminates cleanly. diff --git a/dracut-kdump-error-handler.service b/dracut-kdump-error-handler.service deleted file mode 100644 index a23b75e..0000000 --- a/dracut-kdump-error-handler.service +++ /dev/null @@ -1,33 +0,0 @@ -# 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. - -# This service will run the real kdump error handler code. Executing the -# failure action configured in kdump.conf - -[Unit] -Description=Kdump Error Handler -DefaultDependencies=no -After=systemd-vconsole-setup.service -Wants=systemd-vconsole-setup.service -AllowIsolate=yes - -[Service] -Environment=HOME=/ -Environment=DRACUT_SYSTEMD=1 -Environment=NEWROOT=/sysroot -WorkingDirectory=/ -ExecStart=/bin/kdump-error-handler.sh -Type=oneshot -StandardInput=tty-force -StandardOutput=inherit -StandardError=inherit -KillMode=process -IgnoreSIGPIPE=no - -# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash -# terminates cleanly. -KillSignal=SIGHUP diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 21143b4..ac0f196 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -856,7 +856,6 @@ install() { inst "$moddir/kdump-capture.service" "$systemdsystemunitdir/kdump-capture.service" systemctl -q --root "$initdir" add-wants initrd.target 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 and emergency target cp "$moddir/kdump-emergency.service" "$initdir/$systemdsystemunitdir/emergency.service" cp "$moddir/kdump-emergency.target" "$initdir/$systemdsystemunitdir/emergency.target" diff --git a/kexec-tools.spec b/kexec-tools.spec index 00cf64c..f81b523 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -49,7 +49,6 @@ Source101: dracut-module-setup.sh Source102: dracut-monitor_dd_progress 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 Source108: dracut-early-kdump.sh @@ -228,7 +227,6 @@ cp %{SOURCE101} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb cp %{SOURCE102} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE102}} cp %{SOURCE103} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE103}} 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}}
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Also remove the invalid header comments in service file, the service is not part of systemd code. And sync the service spec with dracut.
Signed-off-by: Kairui Song kasong@redhat.com
dracut-kdump-emergency.service | 25 +++++++++++----------- dracut-kdump-error-handler.service | 33 ------------------------------ dracut-module-setup.sh | 1 - kexec-tools.spec | 2 -- 4 files changed, 12 insertions(+), 49 deletions(-) delete mode 100644 dracut-kdump-error-handler.service
diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service index e023284..f2f6fad 100644 --- a/dracut-kdump-emergency.service +++ b/dracut-kdump-emergency.service @@ -1,27 +1,26 @@ -# 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.
-# This service will be placed in kdump initramfs and replace both the systemd -# emergency service and dracut emergency shell. IOW, any emergency will be -# kick this service and in turn isolating to kdump error handler. +# This service will run the real kdump error handler code. Executing the +# failure action configured in kdump.conf
[Unit] -Description=Kdump Emergency +Description=Kdump Error Handler DefaultDependencies=no -IgnoreOnIsolate=yes +After=systemd-vconsole-setup.service +Wants=systemd-vconsole-setup.service
[Service] -ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service +Environment=HOME=/ +Environment=DRACUT_SYSTEMD=1 +Environment=NEWROOT=/sysroot +WorkingDirectory=/ +ExecStart=/bin/kdump-error-handler.sh +ExecStopPost=-/bin/rm -f -- /.console_lock Type=oneshot StandardInput=tty-force StandardOutput=inherit StandardError=inherit KillMode=process IgnoreSIGPIPE=no +TasksMax=infinity
# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash # terminates cleanly. diff --git a/dracut-kdump-error-handler.service b/dracut-kdump-error-handler.service deleted file mode 100644 index a23b75e..0000000 --- a/dracut-kdump-error-handler.service +++ /dev/null @@ -1,33 +0,0 @@ -# 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.
-# This service will run the real kdump error handler code. Executing the -# failure action configured in kdump.conf
-[Unit] -Description=Kdump Error Handler -DefaultDependencies=no -After=systemd-vconsole-setup.service -Wants=systemd-vconsole-setup.service -AllowIsolate=yes
-[Service] -Environment=HOME=/ -Environment=DRACUT_SYSTEMD=1 -Environment=NEWROOT=/sysroot -WorkingDirectory=/ -ExecStart=/bin/kdump-error-handler.sh -Type=oneshot -StandardInput=tty-force -StandardOutput=inherit -StandardError=inherit -KillMode=process -IgnoreSIGPIPE=no
-# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash -# terminates cleanly. -KillSignal=SIGHUP diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 21143b4..ac0f196 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -856,7 +856,6 @@ install() { inst "$moddir/kdump-capture.service" "$systemdsystemunitdir/kdump-capture.service" systemctl -q --root "$initdir" add-wants initrd.target 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 and emergency target cp "$moddir/kdump-emergency.service" "$initdir/$systemdsystemunitdir/emergency.service" cp "$moddir/kdump-emergency.target" "$initdir/$systemdsystemunitdir/emergency.target"
diff --git a/kexec-tools.spec b/kexec-tools.spec index 00cf64c..f81b523 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -49,7 +49,6 @@ Source101: dracut-module-setup.sh Source102: dracut-monitor_dd_progress 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 Source108: dracut-early-kdump.sh @@ -228,7 +227,6 @@ cp %{SOURCE101} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb cp %{SOURCE102} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE102}} cp %{SOURCE103} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE103}} 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}} -- 2.29.2 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
Same for rootfs over net, and any other rootfs structure.
Also remove the invalid header comments in service file, the service is not part of systemd code. And sync the service spec with dracut.
Signed-off-by: Kairui Song kasong@redhat.com
dracut-kdump-emergency.service | 25 +++++++++++----------- dracut-kdump-error-handler.service | 33 ------------------------------ dracut-module-setup.sh | 1 - kexec-tools.spec | 2 -- 4 files changed, 12 insertions(+), 49 deletions(-) delete mode 100644 dracut-kdump-error-handler.service
diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service index e023284..f2f6fad 100644 --- a/dracut-kdump-emergency.service +++ b/dracut-kdump-emergency.service @@ -1,27 +1,26 @@ -# 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.
-# This service will be placed in kdump initramfs and replace both the systemd -# emergency service and dracut emergency shell. IOW, any emergency will be -# kick this service and in turn isolating to kdump error handler. +# This service will run the real kdump error handler code. Executing the +# failure action configured in kdump.conf
[Unit] -Description=Kdump Emergency +Description=Kdump Error Handler DefaultDependencies=no -IgnoreOnIsolate=yes +After=systemd-vconsole-setup.service +Wants=systemd-vconsole-setup.service
[Service] -ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service +Environment=HOME=/ +Environment=DRACUT_SYSTEMD=1 +Environment=NEWROOT=/sysroot +WorkingDirectory=/ +ExecStart=/bin/kdump-error-handler.sh +ExecStopPost=-/bin/rm -f -- /.console_lock Type=oneshot StandardInput=tty-force StandardOutput=inherit StandardError=inherit KillMode=process IgnoreSIGPIPE=no +TasksMax=infinity
# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash # terminates cleanly. diff --git a/dracut-kdump-error-handler.service b/dracut-kdump-error-handler.service deleted file mode 100644 index a23b75e..0000000 --- a/dracut-kdump-error-handler.service +++ /dev/null @@ -1,33 +0,0 @@ -# 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.
-# This service will run the real kdump error handler code. Executing the -# failure action configured in kdump.conf
-[Unit] -Description=Kdump Error Handler -DefaultDependencies=no -After=systemd-vconsole-setup.service -Wants=systemd-vconsole-setup.service -AllowIsolate=yes
-[Service] -Environment=HOME=/ -Environment=DRACUT_SYSTEMD=1 -Environment=NEWROOT=/sysroot -WorkingDirectory=/ -ExecStart=/bin/kdump-error-handler.sh -Type=oneshot -StandardInput=tty-force -StandardOutput=inherit -StandardError=inherit -KillMode=process -IgnoreSIGPIPE=no
-# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash -# terminates cleanly. -KillSignal=SIGHUP diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 21143b4..ac0f196 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -856,7 +856,6 @@ install() { inst "$moddir/kdump-capture.service" "$systemdsystemunitdir/kdump-capture.service" systemctl -q --root "$initdir" add-wants initrd.target 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 and emergency target cp "$moddir/kdump-emergency.service" "$initdir/$systemdsystemunitdir/emergency.service" cp "$moddir/kdump-emergency.target" "$initdir/$systemdsystemunitdir/emergency.target"
diff --git a/kexec-tools.spec b/kexec-tools.spec index 00cf64c..f81b523 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -49,7 +49,6 @@ Source101: dracut-module-setup.sh Source102: dracut-monitor_dd_progress 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 Source108: dracut-early-kdump.sh @@ -228,7 +227,6 @@ cp %{SOURCE101} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb cp %{SOURCE102} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE102}} cp %{SOURCE103} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE103}} 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}} -- 2.29.2 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Best regards, Coiby
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.service
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Same for rootfs over net, and any other rootfs structure.
Also remove the invalid header comments in service file, the service is not part of systemd code. And sync the service spec with dracut.
Signed-off-by: Kairui Song kasong@redhat.com
dracut-kdump-emergency.service | 25 +++++++++++----------- dracut-kdump-error-handler.service | 33 ------------------------------ dracut-module-setup.sh | 1 - kexec-tools.spec | 2 -- 4 files changed, 12 insertions(+), 49 deletions(-) delete mode 100644 dracut-kdump-error-handler.service
diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service index e023284..f2f6fad 100644 --- a/dracut-kdump-emergency.service +++ b/dracut-kdump-emergency.service @@ -1,27 +1,26 @@ -# 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.
-# This service will be placed in kdump initramfs and replace both the systemd -# emergency service and dracut emergency shell. IOW, any emergency will be -# kick this service and in turn isolating to kdump error handler. +# This service will run the real kdump error handler code. Executing the +# failure action configured in kdump.conf
[Unit] -Description=Kdump Emergency +Description=Kdump Error Handler DefaultDependencies=no -IgnoreOnIsolate=yes +After=systemd-vconsole-setup.service +Wants=systemd-vconsole-setup.service
[Service] -ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service +Environment=HOME=/ +Environment=DRACUT_SYSTEMD=1 +Environment=NEWROOT=/sysroot +WorkingDirectory=/ +ExecStart=/bin/kdump-error-handler.sh +ExecStopPost=-/bin/rm -f -- /.console_lock Type=oneshot StandardInput=tty-force StandardOutput=inherit StandardError=inherit KillMode=process IgnoreSIGPIPE=no +TasksMax=infinity
# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash # terminates cleanly. diff --git a/dracut-kdump-error-handler.service b/dracut-kdump-error-handler.service deleted file mode 100644 index a23b75e..0000000 --- a/dracut-kdump-error-handler.service +++ /dev/null @@ -1,33 +0,0 @@ -# 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.
-# This service will run the real kdump error handler code. Executing the -# failure action configured in kdump.conf
-[Unit] -Description=Kdump Error Handler -DefaultDependencies=no -After=systemd-vconsole-setup.service -Wants=systemd-vconsole-setup.service -AllowIsolate=yes
-[Service] -Environment=HOME=/ -Environment=DRACUT_SYSTEMD=1 -Environment=NEWROOT=/sysroot -WorkingDirectory=/ -ExecStart=/bin/kdump-error-handler.sh -Type=oneshot -StandardInput=tty-force -StandardOutput=inherit -StandardError=inherit -KillMode=process -IgnoreSIGPIPE=no
-# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash -# terminates cleanly. -KillSignal=SIGHUP diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 21143b4..ac0f196 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -856,7 +856,6 @@ install() { inst "$moddir/kdump-capture.service" "$systemdsystemunitdir/kdump-capture.service" systemctl -q --root "$initdir" add-wants initrd.target 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 and emergency target cp "$moddir/kdump-emergency.service" "$initdir/$systemdsystemunitdir/emergency.service" cp "$moddir/kdump-emergency.target" "$initdir/$systemdsystemunitdir/emergency.target"
diff --git a/kexec-tools.spec b/kexec-tools.spec index 00cf64c..f81b523 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -49,7 +49,6 @@ Source101: dracut-module-setup.sh Source102: dracut-monitor_dd_progress 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 Source108: dracut-early-kdump.sh @@ -228,7 +227,6 @@ cp %{SOURCE101} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb cp %{SOURCE102} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE102}} cp %{SOURCE103} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE103}} 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}} -- 2.29.2 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Best regards, Coiby
-- Best Regards, Kairui Song
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.service
Yes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
Same for rootfs over net, and any other rootfs structure.
Also remove the invalid header comments in service file, the service is not part of systemd code. And sync the service spec with dracut.
Signed-off-by: Kairui Song kasong@redhat.com
dracut-kdump-emergency.service | 25 +++++++++++----------- dracut-kdump-error-handler.service | 33 ------------------------------ dracut-module-setup.sh | 1 - kexec-tools.spec | 2 -- 4 files changed, 12 insertions(+), 49 deletions(-) delete mode 100644 dracut-kdump-error-handler.service
diff --git a/dracut-kdump-emergency.service b/dracut-kdump-emergency.service index e023284..f2f6fad 100644 --- a/dracut-kdump-emergency.service +++ b/dracut-kdump-emergency.service @@ -1,27 +1,26 @@ -# 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.
-# This service will be placed in kdump initramfs and replace both the systemd -# emergency service and dracut emergency shell. IOW, any emergency will be -# kick this service and in turn isolating to kdump error handler. +# This service will run the real kdump error handler code. Executing the +# failure action configured in kdump.conf
[Unit] -Description=Kdump Emergency +Description=Kdump Error Handler DefaultDependencies=no -IgnoreOnIsolate=yes +After=systemd-vconsole-setup.service +Wants=systemd-vconsole-setup.service
[Service] -ExecStart=/usr/bin/systemctl --no-block isolate kdump-error-handler.service +Environment=HOME=/ +Environment=DRACUT_SYSTEMD=1 +Environment=NEWROOT=/sysroot +WorkingDirectory=/ +ExecStart=/bin/kdump-error-handler.sh +ExecStopPost=-/bin/rm -f -- /.console_lock Type=oneshot StandardInput=tty-force StandardOutput=inherit StandardError=inherit KillMode=process IgnoreSIGPIPE=no +TasksMax=infinity
# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash # terminates cleanly. diff --git a/dracut-kdump-error-handler.service b/dracut-kdump-error-handler.service deleted file mode 100644 index a23b75e..0000000 --- a/dracut-kdump-error-handler.service +++ /dev/null @@ -1,33 +0,0 @@ -# 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.
-# This service will run the real kdump error handler code. Executing the -# failure action configured in kdump.conf
-[Unit] -Description=Kdump Error Handler -DefaultDependencies=no -After=systemd-vconsole-setup.service -Wants=systemd-vconsole-setup.service -AllowIsolate=yes
-[Service] -Environment=HOME=/ -Environment=DRACUT_SYSTEMD=1 -Environment=NEWROOT=/sysroot -WorkingDirectory=/ -ExecStart=/bin/kdump-error-handler.sh -Type=oneshot -StandardInput=tty-force -StandardOutput=inherit -StandardError=inherit -KillMode=process -IgnoreSIGPIPE=no
-# Bash ignores SIGTERM, so we send SIGHUP instead, to ensure that bash -# terminates cleanly. -KillSignal=SIGHUP diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 21143b4..ac0f196 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -856,7 +856,6 @@ install() { inst "$moddir/kdump-capture.service" "$systemdsystemunitdir/kdump-capture.service" systemctl -q --root "$initdir" add-wants initrd.target 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 and emergency target cp "$moddir/kdump-emergency.service" "$initdir/$systemdsystemunitdir/emergency.service" cp "$moddir/kdump-emergency.target" "$initdir/$systemdsystemunitdir/emergency.target"
diff --git a/kexec-tools.spec b/kexec-tools.spec index 00cf64c..f81b523 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -49,7 +49,6 @@ Source101: dracut-module-setup.sh Source102: dracut-monitor_dd_progress 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 Source108: dracut-early-kdump.sh @@ -228,7 +227,6 @@ cp %{SOURCE101} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpb cp %{SOURCE102} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE102}} cp %{SOURCE103} $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99kdumpbase/%{remove_dracut_prefix %{SOURCE103}} 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}} -- 2.29.2 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Best regards, Coiby
-- Best Regards, Kairui Song
-- Best regards, Coiby
On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.serviceYes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
I thought sysroot.mount is started through systemd in dracut-kdump-emergency.service and systemd will automatically start the services dependent by sysroot.mount. So somehow systemd can't do that and only initqueue can setup all extra requirements?
On Tue, Apr 6, 2021 at 7:46 AM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
The wrapper is introduced in commit 002337c, according to the commit message, the only usage of the wrapper is when dracut-initqueue calls "systemctl start emergency" directly. In that case, emergency is started, but not in a isolation mode, which means dracut-initqueue is still running. On the other hand, emergency will call "systemctl start dracut-initqueue" again when default action is dump_to_rootfs.
systemd would block on the last dracut-initqueue, waiting for the first instance to exit, which leaves us hang.
In previous commit we added initqueue status detect in dump_to_rootfs, so now even without the wrapper, it will not hang.
And actually, previously, with the wrapper, emergency might still hang for like 30s. When dracut called emergency service because initqueue timed out, dump_to_rootfs will try start initqueue again and timeout again. Now with the wrapper removed, we can avoid these two kinds of hangs, bacause without the isolation we can detect initqueue service status correctly in such case.
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.serviceYes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
I thought sysroot.mount is started through systemd in dracut-kdump-emergency.service and systemd will automatically start the services dependent by sysroot.mount. So somehow systemd can't do that and only initqueue can setup all extra requirements?
-- Best regards, Coiby
It depends on the kind of dependency. Still for example, LVM mappers are too complex to be handled by systemd so it need initqueue to setup, and simple service dependency can be handled by systems. And sysroot.mount is a service created by systemd generator so it may miss some service dependency info.
On Tue, Apr 06, 2021 at 09:38:53AM +0800, Kairui Song wrote:
On Tue, Apr 6, 2021 at 7:46 AM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote: >The wrapper is introduced in commit 002337c, according to the commit >message, the only usage of the wrapper is when dracut-initqueue calls >"systemctl start emergency" directly. In that case, emergency >is started, but not in a isolation mode, which means dracut-initqueue >is still running. On the other hand, emergency will call >"systemctl start dracut-initqueue" again when default action is dump_to_rootfs. > >systemd would block on the last dracut-initqueue, waiting for the first >instance to exit, which leaves us hang. > >In previous commit we added initqueue status detect in dump_to_rootfs, >so now even without the wrapper, it will not hang. > >And actually, previously, with the wrapper, emergency might still hang >for like 30s. When dracut called emergency service because initqueue >timed out, dump_to_rootfs will try start initqueue again and timeout >again. Now with the wrapper removed, we can avoid these two kinds of >hangs, bacause without the isolation we can detect initqueue service >status correctly in such case. >
I'm curious why should we start dracut-initqueue again in dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out "systemctl start dracut-initqueue", kdump works fine. And if dracut-iniqueue timed out before (e.g. because the dump target is nfs and there's no response from nfs server), won't dracut-initque time out again if we start it?
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.serviceYes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
I thought sysroot.mount is started through systemd in dracut-kdump-emergency.service and systemd will automatically start the services dependent by sysroot.mount. So somehow systemd can't do that and only initqueue can setup all extra requirements?
-- Best regards, Coiby
It depends on the kind of dependency. Still for example, LVM mappers are too complex to be handled by systemd so it need initqueue to setup, and simple service dependency can be handled by systems. And sysroot.mount is a service created by systemd generator so it may miss some service dependency info.
Got it, thanks!
I have another question. If we restart failed dracut-initqueue.service in dracut-kdump-emergency.service, it could fail gain. Would it restart dracut-initque.service again thus lead to an infinite loop?
O n Tue, Apr 6, 2021 at 10:08 AM Coiby Xu coxu@redhat.com wrote:
On Tue, Apr 06, 2021 at 09:38:53AM +0800, Kairui Song wrote:
On Tue, Apr 6, 2021 at 7:46 AM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote: > > On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote: > >The wrapper is introduced in commit 002337c, according to the commit > >message, the only usage of the wrapper is when dracut-initqueue calls > >"systemctl start emergency" directly. In that case, emergency > >is started, but not in a isolation mode, which means dracut-initqueue > >is still running. On the other hand, emergency will call > >"systemctl start dracut-initqueue" again when default action is dump_to_rootfs. > > > >systemd would block on the last dracut-initqueue, waiting for the first > >instance to exit, which leaves us hang. > > > >In previous commit we added initqueue status detect in dump_to_rootfs, > >so now even without the wrapper, it will not hang. > > > >And actually, previously, with the wrapper, emergency might still hang > >for like 30s. When dracut called emergency service because initqueue > >timed out, dump_to_rootfs will try start initqueue again and timeout > >again. Now with the wrapper removed, we can avoid these two kinds of > >hangs, bacause without the isolation we can detect initqueue service > >status correctly in such case. > > > > I'm curious why should we start dracut-initqueue again in > dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out > "systemctl start dracut-initqueue", kdump works fine. And if > dracut-iniqueue timed out before (e.g. because the dump target is nfs > and there's no response from nfs server), won't dracut-initque time out > again if we start it? >
Hi Coiby,
It depends on how kdump failed, and how rootfs is structured.
If kdump failed before starting initqueue, then it might be necessary to start initqueue.
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.serviceYes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
The initqueue is responsible for a lot of things. eg. setup lvm mappers. If the rootfs is a partition on lvm, we will have to setup lvm mappers first, so we need to ensure the initqueue is started. If the initqueue haven't started yet, kdump can't find the rootfs.
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
I thought sysroot.mount is started through systemd in dracut-kdump-emergency.service and systemd will automatically start the services dependent by sysroot.mount. So somehow systemd can't do that and only initqueue can setup all extra requirements?
-- Best regards, Coiby
It depends on the kind of dependency. Still for example, LVM mappers are too complex to be handled by systemd so it need initqueue to setup, and simple service dependency can be handled by systems. And sysroot.mount is a service created by systemd generator so it may miss some service dependency info.
Got it, thanks!
I have another question. If we restart failed dracut-initqueue.service in dracut-kdump-emergency.service, it could fail gain. Would it restart dracut-initque.service again thus lead to an infinite loop?
Yes, so we have introduced a status check in previous commit, will skip initqueue service if "is-failed" or "is-active" return true.
-- Best Regards, Kairui Song
On Tue, Apr 06, 2021 at 01:33:05PM +0800, Kairui Song wrote:
O n Tue, Apr 6, 2021 at 10:08 AM Coiby Xu coxu@redhat.com wrote:
On Tue, Apr 06, 2021 at 09:38:53AM +0800, Kairui Song wrote:
On Tue, Apr 6, 2021 at 7:46 AM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote: >On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote: >> >> On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote: >> >The wrapper is introduced in commit 002337c, according to the commit >> >message, the only usage of the wrapper is when dracut-initqueue calls >> >"systemctl start emergency" directly. In that case, emergency >> >is started, but not in a isolation mode, which means dracut-initqueue >> >is still running. On the other hand, emergency will call >> >"systemctl start dracut-initqueue" again when default action is dump_to_rootfs. >> > >> >systemd would block on the last dracut-initqueue, waiting for the first >> >instance to exit, which leaves us hang. >> > >> >In previous commit we added initqueue status detect in dump_to_rootfs, >> >so now even without the wrapper, it will not hang. >> > >> >And actually, previously, with the wrapper, emergency might still hang >> >for like 30s. When dracut called emergency service because initqueue >> >timed out, dump_to_rootfs will try start initqueue again and timeout >> >again. Now with the wrapper removed, we can avoid these two kinds of >> >hangs, bacause without the isolation we can detect initqueue service >> >status correctly in such case. >> > >> >> I'm curious why should we start dracut-initqueue again in >> dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out >> "systemctl start dracut-initqueue", kdump works fine. And if >> dracut-iniqueue timed out before (e.g. because the dump target is nfs >> and there's no response from nfs server), won't dracut-initque time out >> again if we start it? >> > >Hi Coiby, > >It depends on how kdump failed, and how rootfs is structured. > >If kdump failed before starting initqueue, then it might be necessary >to start initqueue. >
Thanks for the explaining! But doesn't dracut-kdump-capture.service start after dracut-initqueue.service?
[Unit] Description=Kdump Vmcore Save Service After=initrd.target initrd-parse-etc.service sysroot.mount After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.serviceYes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
>The initqueue is responsible for a lot of things. eg. setup lvm >mappers. If the rootfs is a partition on lvm, we will have to setup >lvm mappers first, so we need to ensure the initqueue is started. If >the initqueue haven't started yet, kdump can't find the rootfs. >
I don't know much about systemd and sysroot.mount. In dump_to_rootfs, "systemctl start sysroot.mount" is called before dumping vmcore? Does it imply setting up lvm mappers will be took proper care because sysroot.mount depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
I thought sysroot.mount is started through systemd in dracut-kdump-emergency.service and systemd will automatically start the services dependent by sysroot.mount. So somehow systemd can't do that and only initqueue can setup all extra requirements?
-- Best regards, Coiby
It depends on the kind of dependency. Still for example, LVM mappers are too complex to be handled by systemd so it need initqueue to setup, and simple service dependency can be handled by systems. And sysroot.mount is a service created by systemd generator so it may miss some service dependency info.
Got it, thanks!
I have another question. If we restart failed dracut-initqueue.service in dracut-kdump-emergency.service, it could fail gain. Would it restart dracut-initque.service again thus lead to an infinite loop?
Yes, so we have introduced a status check in previous commit, will skip initqueue service if "is-failed" or "is-active" return true.
Then you seem to have made a mistake in "[PATCH 1/3] Don's try to restart dracut-initqueue if it's already there" because it will start initqueue when is-failed return true,
+ if ! systemctl is-active dracut-initqueue || systemctl is-failed dracut-initqueue; then + dinfo "Trying to bring up initqueue for rootfs mount" + systemctl start dracut-initqueue + fi +
-- Best Regards, Kairui Song
On Tue, Apr 6, 2021 at 4:20 PM Coiby Xu coxu@redhat.com wrote:
On Tue, Apr 06, 2021 at 01:33:05PM +0800, Kairui Song wrote:
O n Tue, Apr 6, 2021 at 10:08 AM Coiby Xu coxu@redhat.com wrote:
On Tue, Apr 06, 2021 at 09:38:53AM +0800, Kairui Song wrote:
On Tue, Apr 6, 2021 at 7:46 AM Coiby Xu coxu@redhat.com wrote:
On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu coxu@redhat.com wrote: > > On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote: > >On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote: > >> > >> On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote: > >> >The wrapper is introduced in commit 002337c, according to the commit > >> >message, the only usage of the wrapper is when dracut-initqueue calls > >> >"systemctl start emergency" directly. In that case, emergency > >> >is started, but not in a isolation mode, which means dracut-initqueue > >> >is still running. On the other hand, emergency will call > >> >"systemctl start dracut-initqueue" again when default action is dump_to_rootfs. > >> > > >> >systemd would block on the last dracut-initqueue, waiting for the first > >> >instance to exit, which leaves us hang. > >> > > >> >In previous commit we added initqueue status detect in dump_to_rootfs, > >> >so now even without the wrapper, it will not hang. > >> > > >> >And actually, previously, with the wrapper, emergency might still hang > >> >for like 30s. When dracut called emergency service because initqueue > >> >timed out, dump_to_rootfs will try start initqueue again and timeout > >> >again. Now with the wrapper removed, we can avoid these two kinds of > >> >hangs, bacause without the isolation we can detect initqueue service > >> >status correctly in such case. > >> > > >> > >> I'm curious why should we start dracut-initqueue again in > >> dump_to_rootfs? When failure_action=dump_to_rootfs and I comment out > >> "systemctl start dracut-initqueue", kdump works fine. And if > >> dracut-iniqueue timed out before (e.g. because the dump target is nfs > >> and there's no response from nfs server), won't dracut-initque time out > >> again if we start it? > >> > > > >Hi Coiby, > > > >It depends on how kdump failed, and how rootfs is structured. > > > >If kdump failed before starting initqueue, then it might be necessary > >to start initqueue. > > > > Thanks for the explaining! But doesn't dracut-kdump-capture.service > start after dracut-initqueue.service? > > [Unit] > Description=Kdump Vmcore Save Service > After=initrd.target initrd-parse-etc.service sysroot.mount > After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.service >
Yes, but the kdump initramfs may jump to emergency.target direct if some service failed, that will start our emergency helper direct, no matter which stage the kdump capture environment is currently at.
> >The initqueue is responsible for a lot of things. eg. setup lvm > >mappers. If the rootfs is a partition on lvm, we will have to setup > >lvm mappers first, so we need to ensure the initqueue is started. If > >the initqueue haven't started yet, kdump can't find the rootfs. > > > > I don't know much about systemd and sysroot.mount. In dump_to_rootfs, > "systemctl start sysroot.mount" is called before dumping vmcore? Does it > imply setting up lvm mappers will be took proper care because sysroot.mount > depends on it?
Yes, sysroot.mount will start after initqueue, and that should be enough. initqueue will setup all extra requirements for sysroot.mount
I thought sysroot.mount is started through systemd in dracut-kdump-emergency.service and systemd will automatically start the services dependent by sysroot.mount. So somehow systemd can't do that and only initqueue can setup all extra requirements?
-- Best regards, Coiby
It depends on the kind of dependency. Still for example, LVM mappers are too complex to be handled by systemd so it need initqueue to setup, and simple service dependency can be handled by systems. And sysroot.mount is a service created by systemd generator so it may miss some service dependency info.
Got it, thanks!
I have another question. If we restart failed dracut-initqueue.service in dracut-kdump-emergency.service, it could fail gain. Would it restart dracut-initque.service again thus lead to an infinite loop?
Yes, so we have introduced a status check in previous commit, will skip initqueue service if "is-failed" or "is-active" return true.
Then you seem to have made a mistake in "[PATCH 1/3] Don's try to restart dracut-initqueue if it's already there" because it will start initqueue when is-failed return true,
- if ! systemctl is-active dracut-initqueue || systemctl is-failed dracut-initqueue; then
dinfo "Trying to bring up initqueue for rootfs mount"systemctl start dracut-initqueue- fi
Ah, yes, I missed a bracket, it should be:
if ! ( systemctl is-active dracut-initqueue || systemctl is-failed dracut-initqueue ); then
Let me update the patch.
-- Best Regards, Kairui Song
Use a modified and minimized version of emergency shell. The differences of this kdump shell and dracut emergency shell are:
- Kdump shell won't generate a rdsosreport automatically - Customized prompts - Never ask root password - Won't tangle with dracut's emergency_action. If emergency_action is set, dracut emergency shell will perform dracut's emergency_action instead of kdump final_action on exit. - If rd.shell=no is set, kdump shell will still work, dracut emergency shell won't, even if kdump failure_action is set to shell.
Signed-off-by: Kairui Song kasong@redhat.com --- kdump-lib-initramfs.sh | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7198db1..d03f981 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -231,10 +231,35 @@ dump_to_rootfs()
kdump_emergency_shell() { - echo "PS1="kdump:\${PWD}# "" >/etc/profile - ddebug "Switching to dracut emergency..." - /bin/dracut-emergency - rm -f /etc/profile + ddebug "Switching to kdump emergency shell..." + + [ -f /etc/profile ] && . /etc/profile + export PS1='kdump:\${PWD}# ' + + . /lib/dracut-lib.sh + if [ -f /dracut-state.sh ]; then + . /dracut-state.sh 2>/dev/null + fi + + source_conf /etc/conf.d + + type plymouth >/dev/null 2>&1 && plymouth quit + + source_hook "emergency" + while read _tty rest; do + ( + echo + echo + echo 'Entering kdump emergency mode.' + echo 'Type "journalctl" to view system logs.' + echo 'Type "rdsosreport" to generate a sosreport, you can then' + echo 'save it elsewhere and attach it to a bug report.' + echo + echo + ) > /dev/$_tty + done < /proc/consoles + sh -i -l + /bin/rm -f -- /.console_lock }
do_failure_action()
On Thu, Mar 18, 2021 at 01:12:31PM +0800, Kairui Song wrote:
Use a modified and minimized version of emergency shell. The differences of this kdump shell and dracut emergency shell are:
- Kdump shell won't generate a rdsosreport automatically
- Customized prompts
- Never ask root password
- Won't tangle with dracut's emergency_action. If emergency_action is set, dracut emergency shell will perform dracut's emergency_action instead of kdump final_action on exit.
- If rd.shell=no is set, kdump shell will still work, dracut emergency shell won't, even if kdump failure_action is set to shell.
Signed-off-by: Kairui Song kasong@redhat.com
kdump-lib-initramfs.sh | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7198db1..d03f981 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -231,10 +231,35 @@ dump_to_rootfs()
kdump_emergency_shell() {
- echo "PS1="kdump:\${PWD}# "" >/etc/profile
- ddebug "Switching to dracut emergency..."
- /bin/dracut-emergency
- rm -f /etc/profile
- ddebug "Switching to kdump emergency shell..."
- [ -f /etc/profile ] && . /etc/profile
- export PS1='kdump:\${PWD}# '
Since you use "'", you shouldn't escape "$", i.e., export PS1='kdump:${PWD}# '.
Btw, even if you use double quotes, "" doesn't need to be escaped, i.e., PS1="kdump:${PWD}# "
- . /lib/dracut-lib.sh
- if [ -f /dracut-state.sh ]; then
. /dracut-state.sh 2>/dev/null- fi
- source_conf /etc/conf.d
- type plymouth >/dev/null 2>&1 && plymouth quit
- source_hook "emergency"
- while read _tty rest; do
(echoechoecho 'Entering kdump emergency mode.'echo 'Type "journalctl" to view system logs.'echo 'Type "rdsosreport" to generate a sosreport, you can then'echo 'save it elsewhere and attach it to a bug report.'echoecho) > /dev/$_tty- done < /proc/consoles
- sh -i -l
- /bin/rm -f -- /.console_lock
}
do_failure_action()
2.29.2 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu coxu@redhat.com wrote:
On Thu, Mar 18, 2021 at 01:12:31PM +0800, Kairui Song wrote:
Use a modified and minimized version of emergency shell. The differences of this kdump shell and dracut emergency shell are:
- Kdump shell won't generate a rdsosreport automatically
- Customized prompts
- Never ask root password
- Won't tangle with dracut's emergency_action. If emergency_action is set, dracut emergency shell will perform dracut's emergency_action instead of kdump final_action on exit.
- If rd.shell=no is set, kdump shell will still work, dracut emergency shell won't, even if kdump failure_action is set to shell.
Signed-off-by: Kairui Song kasong@redhat.com
kdump-lib-initramfs.sh | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7198db1..d03f981 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -231,10 +231,35 @@ dump_to_rootfs()
kdump_emergency_shell() {
- echo "PS1="kdump:\${PWD}# "" >/etc/profile
- ddebug "Switching to dracut emergency..."
- /bin/dracut-emergency
- rm -f /etc/profile
- ddebug "Switching to kdump emergency shell..."
- [ -f /etc/profile ] && . /etc/profile
- export PS1='kdump:\${PWD}# '
Since you use "'", you shouldn't escape "$", i.e., export PS1='kdump:${PWD}# '.
Thanks, good point!
WIll update this.
Btw, even if you use double quotes, "" doesn't need to be escaped, i.e., PS1="kdump:${PWD}# "
- . /lib/dracut-lib.sh
- if [ -f /dracut-state.sh ]; then
. /dracut-state.sh 2>/dev/null- fi
- source_conf /etc/conf.d
- type plymouth >/dev/null 2>&1 && plymouth quit
- source_hook "emergency"
- while read _tty rest; do
(echoechoecho 'Entering kdump emergency mode.'echo 'Type "journalctl" to view system logs.'echo 'Type "rdsosreport" to generate a sosreport, you can then'echo 'save it elsewhere and attach it to a bug report.'echoecho) > /dev/$_tty- done < /proc/consoles
- sh -i -l
- /bin/rm -f -- /.console_lock
}
do_failure_action()
2.29.2 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Best regards, Coiby
-
Coiby Xu -
Kairui Song