Hi,
This is about handling the shutdown path in kdump boot, including two small pieces.
As Vivek suggested, systemd now will take care of the reboot/poweroff/halt and also unmount everything (including dump target). It's like what a normal boot does, and among all the advantanges, at least we don't have to worry about the data sync issue any more. systemd would do all that for us.
Any objection to this switch?
WANG Chao (2): do not force shutdown Let systemd handle unmount
kdump-lib-initramfs.sh | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
It's more safe to use systemd (init) to control the shutdown path for us in either reboot or power off or halt action.
Signed-off-by: WANG Chao chaowang@redhat.com --- kdump-lib-initramfs.sh | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 1517712..6927d27 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,14 +6,14 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="reboot -f" +DEFAULT_ACTION="reboot" DATEDIR=`date +%Y.%m.%d-%T` HOST_IP='127.0.0.1' DUMP_INSTRUCTION="" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" KDUMP_SCRIPT_DIR="/kdumpscripts" DD_BLKSIZE=512 -FINAL_ACTION="reboot -f" +FINAL_ACTION="reboot" KDUMP_CONF="/etc/kdump.conf" KDUMP_PRE="" KDUMP_POST="" @@ -59,13 +59,13 @@ get_kdump_confs() DEFAULT_ACTION="kdump_emergency_shell" ;; reboot) - DEFAULT_ACTION="do_umount; reboot -f" + DEFAULT_ACTION="do_umount; reboot" ;; halt) - DEFAULT_ACTION="do_umount; halt -f" + DEFAULT_ACTION="do_umount; halt" ;; poweroff) - DEFAULT_ACTION="do_umount; poweroff -f" + DEFAULT_ACTION="do_umount; poweroff" ;; dump_to_rootfs) DEFAULT_ACTION="dump_to_rootfs"
Since we've use systemd to control the shutdown path, there's not need for us to unmount the filesystem, systemd will do that for us just like it does in a normal boot.
Signed-off-by: WANG Chao chaowang@redhat.com --- kdump-lib-initramfs.sh | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 6927d27..f882b09 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -59,13 +59,13 @@ get_kdump_confs() DEFAULT_ACTION="kdump_emergency_shell" ;; reboot) - DEFAULT_ACTION="do_umount; reboot" + DEFAULT_ACTION="reboot" ;; halt) - DEFAULT_ACTION="do_umount; halt" + DEFAULT_ACTION="halt" ;; poweroff) - DEFAULT_ACTION="do_umount; poweroff" + DEFAULT_ACTION="poweroff" ;; dump_to_rootfs) DEFAULT_ACTION="dump_to_rootfs" @@ -153,11 +153,6 @@ kdump_emergency_shell() rm -f /etc/profile }
-do_umount() -{ - umount -Rf $NEWROOT -} - do_default_action() { echo "Kdump: Executing default action $DEFAULT_ACTION" @@ -166,6 +161,5 @@ do_default_action()
do_final_action() { - do_umount eval $FINAL_ACTION }
On Tue, Aug 05, 2014 at 01:31:07PM +0800, WANG Chao wrote:
Hi,
This is about handling the shutdown path in kdump boot, including two small pieces.
As Vivek suggested, systemd now will take care of the reboot/poweroff/halt and also unmount everything (including dump target). It's like what a normal boot does, and among all the advantanges, at least we don't have to worry about the data sync issue any more. systemd would do all that for us.
Any objection to this switch?
I am fine with this change. Only downside I can think of is OOM situation. It might happen that reboot might not work in low memory situation.
Let us commit this change and see how well does it work.
Acked-by: Vivek Goyal vgoyal@redhat.com
Vivek
On 08/05/14 at 08:38am, Vivek Goyal wrote:
On Tue, Aug 05, 2014 at 01:31:07PM +0800, WANG Chao wrote:
Hi,
This is about handling the shutdown path in kdump boot, including two small pieces.
As Vivek suggested, systemd now will take care of the reboot/poweroff/halt and also unmount everything (including dump target). It's like what a normal boot does, and among all the advantanges, at least we don't have to worry about the data sync issue any more. systemd would do all that for us.
Any objection to this switch?
I am fine with this change. Only downside I can think of is OOM situation. It might happen that reboot might not work in low memory situation.
I think it's more likely to kill makedumpfile or dhclient (ssh/nfs case) or some tasks with a high oom-killer score. I wouldn't worry too much about error handler being killed. Anyway let's see.
Thanks for review!