Re: [PATCH] kdump-lib-initramfs.sh: use -f option for failure_action halt

[Kairui Song]

On Wed, Oct 30, 2019 at 9:02 AM [e-mail]
 wrote:
> > -----Original Message-----
> > From: Kairui Song [mailto:[e-mail]]
> > Sent: Monday, October 28, 2019 5:29 PM
> > To: Hatayama, Daisuke/畑山 大輔 
> > Subject: Re: [PATCH] kdump-lib-initramfs.sh: use -f option for failure_action
> > halt
> >
> > On Mon, Oct 28, 2019 at 11:29 AM [e-mail]
> >  wrote:
> > > failure_action halt doesn't work well now. This appears to be similar
> > > to the previous issues such as
> > > b2534348199ad5010c86890a068653d970c9933d and
> > > 89565289c64aa5323278cf5722c725a58b369af8.
> >
> > Hi,
> >
> > Thanks for the patch, it looks good to me in general, but can you add
> > more detail about the problem you are trying to solve?
> > Eg, add some word about the system behavior or some error logs. Like
> > in the two commits you mentioned.
>
> I see. I'll reflect your comment in the next version.
>
> I would write that there is a message indicating halt command is executed
> but actually system is reboot, not halted together with log message.
>
> Also I a little more looked into the behavior using debug message
> with systemd.log-leve=debug. It looks that systemd-halt.service
> is once pulled-in but it is somehow not executed and finally system
> is rebooted.
>
> systemd-udevd-control.socket: Changed listening -> dead
> systemd-udevd-control.socket: Job 100 systemd-udevd-control.socket/stop finished, result=done
>
> [^[[0;32m  OK  ^[[0m] Closed ^[[0;1;39mudev Control Socket^[[0m.
> Kdump: Executing failure action halt
>
> ^-- failure_action halt is executed
>
> Bus private-bus-connection: changing state UNSET → OPENING
> Bus private-bus-connection: changing state OPENING → AUTHENTICATING
> Accepted new private connection.
> Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/\
> a
> halt.target: Trying to enqueue job halt.target/start/replace-irreversibly
>
> ^-- halt.target gets started being pulled-in here
>
> Added job halt.target/start to transaction.
> Pulling in systemd-halt.service/start from halt.target/start
> Added job systemd-halt.service/start to transaction.
> Pulling in shutdown.target/start from systemd-halt.service/start
> Added job shutdown.target/start to transaction.
> Pulling in dracut-cmdline.service/stop from shutdown.target/start
> Added job dracut-cmdline.service/stop to transaction.
> Pulling in cryptsetup.target/stop from shutdown.target/start
> Added job cryptsetup.target/stop to transaction.
> ...<snip>...
> squash-root.mount: squash-root.mount lost dependency After=dev-loop0.device
> squash-root.mount: squash-root.mount lost dependency References=dev-loop0.device
> squash-root.mount: Collecting.
> Child 400 (umount) died (code=exited, status=0/SUCCESS)
> etc.mount: Child 400 belongs to etc.mount.
> etc.mount: Mount process exited, code=exited, status=0/SUCCESS
> etc.mount: Succeeded.
> etc.mount: Changed unmounting -> dead
> etc.mount: Job 181 etc.mount/stop finished, result=done
> [^[[0;32m  OK  ^[[0m] Unmounted ^[[0;1;39m/etc^[[0m.
> etc.mount: Collecting.
> Received SIGCHLD from PID 400 (n/a).
> inotify event for /etc/localtime
> Failed to stat /etc/localtime, ignoring: No such file or directory
> /etc/localtime doesn't exist yet, watching /etc instead.
> Timezone has been changed (now: UTC).
> Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/aO\
> perating on architecture: x86-64
>
> Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
> Shutting down.
> Bus private-bus-connection: changing state RUNNING → CLOSING
> dev-vda.device: Failed to send unit remove signal for dev-vda.device: Connection reset by peer
> systemd-journald.service: Executing: /usr/lib/systemd/systemd-journald
> Bus private-bus-connection: changing state CLOSING → CLOSED
> [   15.956995] Unregister pv shared memory for cpu 0
> [   15.967559] reboot: Restarting system
> [   15.970216] reboot: machine restart
>
> ^---- but finally system gets restarted.
>
> This behavior doesn't change even if I changed ExecStart=/usr/bin/systemctl --force halt
> in systemd-halt.service into ExecStart=/usr/bin/systemctl --force --force halt.
> systemctl halt with --force twice means systemctl calls immediately directly reboot
> system call. Thus, I think systemd somehow reboot system before entering systemd-halt.service.

Thanks, I remember Pingfan have encountered similar problem before,
that force shutdown turns into reboot and that seems to be a systemd
bug. CC Pingfan see if he has any idea about this.

But it's very strange that systemctl --force --force halt doesn't work
either. I can reproduce this locally with Fedora.

Also add the missing [e-mail] in CC list.

--
Best Regards,
Kairui Song

[PATCH] kdump-lib-initramfs.sh: use -f option for failure_action halt

> -----Original Message-----
> From: Kairui Song [mailto:[e-mail]]
> Sent: Wednesday, October 30, 2019 11:58 AM
> To: Hatayama, Daisuke/畑山 大輔 
> Cc: [e-mail]; Pingfan Liu 
> Subject: Re: [PATCH] kdump-lib-initramfs.sh: use -f option for failure_action
> halt
>
> On Wed, Oct 30, 2019 at 9:02 AM [e-mail]
>  wrote:
> > > -----Original Message-----
> > > From: Kairui Song [mailto:[e-mail]]
> > > Sent: Monday, October 28, 2019 5:29 PM
> > > To: Hatayama, Daisuke/畑山 大輔 
> > > Subject: Re: [PATCH] kdump-lib-initramfs.sh: use -f option for
>
> failure_action
> > > halt
> > >
> > > On Mon, Oct 28, 2019 at 11:29 AM [e-mail]
> > >  wrote:
> > > > failure_action halt doesn't work well now. This appears to be similar
> > > > to the previous issues such as
> > > > b2534348199ad5010c86890a068653d970c9933d and
> > > > 89565289c64aa5323278cf5722c725a58b369af8.
> > >
> > > Hi,
> > >
> > > Thanks for the patch, it looks good to me in general, but can you add
> > > more detail about the problem you are trying to solve?
> > > Eg, add some word about the system behavior or some error logs. Like
> > > in the two commits you mentioned.
> >
> > I see. I'll reflect your comment in the next version.
> >
> > I would write that there is a message indicating halt command is executed
> > but actually system is reboot, not halted together with log message.
> >
> > Also I a little more looked into the behavior using debug message
> > with systemd.log-leve=debug. It looks that systemd-halt.service
> > is once pulled-in but it is somehow not executed and finally system
> > is rebooted.
> >
> > systemd-udevd-control.socket: Changed listening -> dead
> > systemd-udevd-control.socket: Job 100 systemd-udevd-control.socket/stop
>
> finished, result=done
> > [^[[0;32m  OK  ^[[0m] Closed ^[[0;1;39mudev Control Socket^[[0m.
> > Kdump: Executing failure action halt
> >
> > ^-- failure_action halt is executed
> >
> > Bus private-bus-connection: changing state UNSET → OPENING
> > Bus private-bus-connection: changing state OPENING → AUTHENTICATING
> > Accepted new private connection.
> > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > Got message type=method_call sender=n/a
>
> destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1
> reply_cookie=0 signature=ss error-name=n/a error-message=n/\
> > a
> > halt.target: Trying to enqueue job halt.target/start/replace-irreversibly
> >
> > ^-- halt.target gets started being pulled-in here
> >
> > Added job halt.target/start to transaction.
> > Pulling in systemd-halt.service/start from halt.target/start
> > Added job systemd-halt.service/start to transaction.
> > Pulling in shutdown.target/start from systemd-halt.service/start
> > Added job shutdown.target/start to transaction.
> > Pulling in dracut-cmdline.service/stop from shutdown.target/start
> > Added job dracut-cmdline.service/stop to transaction.
> > Pulling in cryptsetup.target/stop from shutdown.target/start
> > Added job cryptsetup.target/stop to transaction.
> > ...<snip>...
> > squash-root.mount: squash-root.mount lost dependency
>
> After=dev-loop0.device
> > squash-root.mount: squash-root.mount lost dependency
>
> References=dev-loop0.device
> > squash-root.mount: Collecting.
> > Child 400 (umount) died (code=exited, status=0/SUCCESS)
> > etc.mount: Child 400 belongs to etc.mount.
> > etc.mount: Mount process exited, code=exited, status=0/SUCCESS
> > etc.mount: Succeeded.
> > etc.mount: Changed unmounting -> dead
> > etc.mount: Job 181 etc.mount/stop finished, result=done
> > [^[[0;32m  OK  ^[[0m] Unmounted ^[[0;1;39m/etc^[[0m.
> > etc.mount: Collecting.
> > Received SIGCHLD from PID 400 (n/a).
> > inotify event for /etc/localtime
> > Failed to stat /etc/localtime, ignoring: No such file or directory
> > /etc/localtime doesn't exist yet, watching /etc instead.
> > Timezone has been changed (now: UTC).
> > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > Got message type=method_call sender=n/a
>
> destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1
> reply_cookie=0 signature=n/a error-name=n/a error-message=n/aO\
> > perating on architecture: x86-64
> >
> > Sent message type=method_return sender=org.freedesktop.systemd1
>
> destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1
> signature=n/a error-name=n/a error-message=n/a
> > Shutting down.
> > Bus private-bus-connection: changing state RUNNING → CLOSING
> > dev-vda.device: Failed to send unit remove signal for dev-vda.device:
>
> Connection reset by peer
> > systemd-journald.service: Executing: /usr/lib/systemd/systemd-journald
> > Bus private-bus-connection: changing state CLOSING → CLOSED
> > [   15.956995] Unregister pv shared memory for cpu 0
> > [   15.967559] reboot: Restarting system
> > [   15.970216] reboot: machine restart
> >
> > ^---- but finally system gets restarted.
> >
> > This behavior doesn't change even if I changed ExecStart=/usr/bin/systemctl
>
> --force halt
> > in systemd-halt.service into ExecStart=/usr/bin/systemctl --force --force
>
> halt.
> > systemctl halt with --force twice means systemctl calls immediately directly
>
> reboot
> > system call. Thus, I think systemd somehow reboot system before entering
>
> systemd-halt.service.
> >
>
> Thanks, I remember Pingfan have encountered similar problem before,
> that force shutdown turns into reboot and that seems to be a systemd
> bug. CC Pingfan see if he has any idea about this.
>
> But it's very strange that systemctl --force --force halt doesn't work
> either. I can reproduce this locally with Fedora.

I meant that thus systemctl --force --force halt actually is executed
because shutdown is executed earlier for some reason.
> Also add the missing [e-mail] in CC list.
>
> --
> Best Regards,
> Kairui Song

[PATCH] kdump-lib-initramfs.sh: use -f option for failure_action halt

[piliu]

On 10/30/2019 10:57 AM, Kairui Song wrote:
> On Wed, Oct 30, 2019 at 9:02 AM [e-mail]
>  wrote:
> > > -----Original Message-----
> > > From: Kairui Song [mailto:[e-mail]]
> > > Sent: Monday, October 28, 2019 5:29 PM
> > > To: Hatayama, Daisuke/畑山 大輔 
> > > Subject: Re: [PATCH] kdump-lib-initramfs.sh: use -f option for failure_action
> > > halt
> > >
> > > On Mon, Oct 28, 2019 at 11:29 AM [e-mail]
> > >  wrote:
> > > > failure_action halt doesn't work well now. This appears to be similar
> > > > to the previous issues such as
> > > > b2534348199ad5010c86890a068653d970c9933d and
> > > > 89565289c64aa5323278cf5722c725a58b369af8.
> > >
> > > Hi,
> > >
> > > Thanks for the patch, it looks good to me in general, but can you add
> > > more detail about the problem you are trying to solve?
> > > Eg, add some word about the system behavior or some error logs. Like
> > > in the two commits you mentioned.
> >
> > I see. I'll reflect your comment in the next version.
> >
> > I would write that there is a message indicating halt command is executed
> > but actually system is reboot, not halted together with log message.
> >
> > Also I a little more looked into the behavior using debug message
> > with systemd.log-leve=debug. It looks that systemd-halt.service
> > is once pulled-in but it is somehow not executed and finally system
> > is rebooted.
> >
> > systemd-udevd-control.socket: Changed listening -> dead
> > systemd-udevd-control.socket: Job 100 systemd-udevd-control.socket/stop finished, result=done
> >
> > [^[[0;32m  OK  ^[[0m] Closed ^[[0;1;39mudev Control Socket^[[0m.
> > Kdump: Executing failure action halt
> >
> > ^-- failure_action halt is executed
> >
> > Bus private-bus-connection: changing state UNSET → OPENING
> > Bus private-bus-connection: changing state OPENING → AUTHENTICATING
> > Accepted new private connection.
> > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/\
> > a
> > halt.target: Trying to enqueue job halt.target/start/replace-irreversibly
> >
> > ^-- halt.target gets started being pulled-in here
> >
> > Added job halt.target/start to transaction.
> > Pulling in systemd-halt.service/start from halt.target/start
> > Added job systemd-halt.service/start to transaction.
> > Pulling in shutdown.target/start from systemd-halt.service/start
> > Added job shutdown.target/start to transaction.
> > Pulling in dracut-cmdline.service/stop from shutdown.target/start
> > Added job dracut-cmdline.service/stop to transaction.
> > Pulling in cryptsetup.target/stop from shutdown.target/start
> > Added job cryptsetup.target/stop to transaction.
> > ...<snip>...
> > squash-root.mount: squash-root.mount lost dependency After=dev-loop0.device
> > squash-root.mount: squash-root.mount lost dependency References=dev-loop0.device
> > squash-root.mount: Collecting.
> > Child 400 (umount) died (code=exited, status=0/SUCCESS)
> > etc.mount: Child 400 belongs to etc.mount.
> > etc.mount: Mount process exited, code=exited, status=0/SUCCESS
> > etc.mount: Succeeded.
> > etc.mount: Changed unmounting -> dead
> > etc.mount: Job 181 etc.mount/stop finished, result=done
> > [^[[0;32m  OK  ^[[0m] Unmounted ^[[0;1;39m/etc^[[0m.
> > etc.mount: Collecting.
> > Received SIGCHLD from PID 400 (n/a).
> > inotify event for /etc/localtime
> > Failed to stat /etc/localtime, ignoring: No such file or directory
> > /etc/localtime doesn't exist yet, watching /etc instead.
> > Timezone has been changed (now: UTC).
> > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/aO\
> > perating on architecture: x86-64
> >
> > Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
> > Shutting down.
> > Bus private-bus-connection: changing state RUNNING → CLOSING
> > dev-vda.device: Failed to send unit remove signal for dev-vda.device: Connection reset by peer
> > systemd-journald.service: Executing: /usr/lib/systemd/systemd-journald
> > Bus private-bus-connection: changing state CLOSING → CLOSED
> > [   15.956995] Unregister pv shared memory for cpu 0
> > [   15.967559] reboot: Restarting system
> > [   15.970216] reboot: machine restart
> >
> > ^---- but finally system gets restarted.
> >
> > This behavior doesn't change even if I changed ExecStart=/usr/bin/systemctl --force halt
> > in systemd-halt.service into ExecStart=/usr/bin/systemctl --force --force halt.
> > systemctl halt with --force twice means systemctl calls immediately directly reboot
> > system call. Thus, I think systemd somehow reboot system before entering systemd-halt.service.
>
> Thanks, I remember Pingfan have encountered similar problem before,
> that force shutdown turns into reboot and that seems to be a systemd
> bug. CC Pingfan see if he has any idea about this.

Yes, you can refer to commit 89565289c64aa5323278cf5722c725a58b369af8
kdump-lib-initramfs.sh: using -force option when poweroff

It is a systemd flaw
> But it's very strange that systemctl --force --force halt doesn't work
> either. I can reproduce this locally with Fedora.
>
> Also add the missing [e-mail] in CC list.
>
> --
> Best Regards,
> Kairui Song

[PATCH] kdump-lib-initramfs.sh: use -f option for failure_action halt

[Kairui Song]

On Wed, Oct 30, 2019 at 12:11 PM piliu  wrote:
> On 10/30/2019 10:57 AM, Kairui Song wrote:
> > On Wed, Oct 30, 2019 at 9:02 AM [e-mail]
> >  wrote:
> > > > -----Original Message-----
> > > > From: Kairui Song [mailto:[e-mail]]
> > > > Sent: Monday, October 28, 2019 5:29 PM
> > > > To: Hatayama, Daisuke/畑山 大輔 
> > > > Subject: Re: [PATCH] kdump-lib-initramfs.sh: use -f option for failure_action
> > > > halt
> > > >
> > > > On Mon, Oct 28, 2019 at 11:29 AM [e-mail]
> > > >  wrote:
> > > > > failure_action halt doesn't work well now. This appears to be similar
> > > > > to the previous issues such as
> > > > > b2534348199ad5010c86890a068653d970c9933d and
> > > > > 89565289c64aa5323278cf5722c725a58b369af8.
> > > >
> > > > Hi,
> > > >
> > > > Thanks for the patch, it looks good to me in general, but can you add
> > > > more detail about the problem you are trying to solve?
> > > > Eg, add some word about the system behavior or some error logs. Like
> > > > in the two commits you mentioned.
> > >
> > > I see. I'll reflect your comment in the next version.
> > >
> > > I would write that there is a message indicating halt command is executed
> > > but actually system is reboot, not halted together with log message.
> > >
> > > Also I a little more looked into the behavior using debug message
> > > with systemd.log-leve=debug. It looks that systemd-halt.service
> > > is once pulled-in but it is somehow not executed and finally system
> > > is rebooted.
> > >
> > > systemd-udevd-control.socket: Changed listening -> dead
> > > systemd-udevd-control.socket: Job 100 systemd-udevd-control.socket/stop finished, result=done
> > >
> > > [^[[0;32m  OK  ^[[0m] Closed ^[[0;1;39mudev Control Socket^[[0m.
> > > Kdump: Executing failure action halt
> > >
> > > ^-- failure_action halt is executed
> > >
> > > Bus private-bus-connection: changing state UNSET → OPENING
> > > Bus private-bus-connection: changing state OPENING → AUTHENTICATING
> > > Accepted new private connection.
> > > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > > Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/\
> > > a
> > > halt.target: Trying to enqueue job halt.target/start/replace-irreversibly
> > >
> > > ^-- halt.target gets started being pulled-in here
> > >
> > > Added job halt.target/start to transaction.
> > > Pulling in systemd-halt.service/start from halt.target/start
> > > Added job systemd-halt.service/start to transaction.
> > > Pulling in shutdown.target/start from systemd-halt.service/start
> > > Added job shutdown.target/start to transaction.
> > > Pulling in dracut-cmdline.service/stop from shutdown.target/start
> > > Added job dracut-cmdline.service/stop to transaction.
> > > Pulling in cryptsetup.target/stop from shutdown.target/start
> > > Added job cryptsetup.target/stop to transaction.
> > > ...<snip>...
> > > squash-root.mount: squash-root.mount lost dependency After=dev-loop0.device
> > > squash-root.mount: squash-root.mount lost dependency References=dev-loop0.device
> > > squash-root.mount: Collecting.
> > > Child 400 (umount) died (code=exited, status=0/SUCCESS)
> > > etc.mount: Child 400 belongs to etc.mount.
> > > etc.mount: Mount process exited, code=exited, status=0/SUCCESS
> > > etc.mount: Succeeded.
> > > etc.mount: Changed unmounting -> dead
> > > etc.mount: Job 181 etc.mount/stop finished, result=done
> > > [^[[0;32m  OK  ^[[0m] Unmounted ^[[0;1;39m/etc^[[0m.
> > > etc.mount: Collecting.
> > > Received SIGCHLD from PID 400 (n/a).
> > > inotify event for /etc/localtime
> > > Failed to stat /etc/localtime, ignoring: No such file or directory
> > > /etc/localtime doesn't exist yet, watching /etc instead.
> > > Timezone has been changed (now: UTC).
> > > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > > Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/aO\
> > > perating on architecture: x86-64
> > >
> > > Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
> > > Shutting down.
> > > Bus private-bus-connection: changing state RUNNING → CLOSING
> > > dev-vda.device: Failed to send unit remove signal for dev-vda.device: Connection reset by peer
> > > systemd-journald.service: Executing: /usr/lib/systemd/systemd-journald
> > > Bus private-bus-connection: changing state CLOSING → CLOSED
> > > [   15.956995] Unregister pv shared memory for cpu 0
> > > [   15.967559] reboot: Restarting system
> > > [   15.970216] reboot: machine restart
> > >
> > > ^---- but finally system gets restarted.
> > >
> > > This behavior doesn't change even if I changed ExecStart=/usr/bin/systemctl --force halt
> > > in systemd-halt.service into ExecStart=/usr/bin/systemctl --force --force halt.
> > > systemctl halt with --force twice means systemctl calls immediately directly reboot
> > > system call. Thus, I think systemd somehow reboot system before entering systemd-halt.service.
> >
> > Thanks, I remember Pingfan have encountered similar problem before,
> > that force shutdown turns into reboot and that seems to be a systemd
> > bug. CC Pingfan see if he has any idea about this.
>
> Yes, you can refer to commit 89565289c64aa5323278cf5722c725a58b369af8
> kdump-lib-initramfs.sh: using -force option when poweroff
>
> It is a systemd flaw
> > But it's very strange that systemctl --force --force halt doesn't work
> > either. I can reproduce this locally with Fedora.
> >
> > Also add the missing [e-mail] in CC list.

Hi Pingfan, Dave, Hatayama

How do you think about some changes like this? Maybe it's time to stop
doing final action if failure action is shutdown/reboot/halt.
I did some simple test and it seems worked well.

diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
index c409dce..8530556 100755
--- a/kdump-lib-initramfs.sh
+++ b/kdump-lib-initramfs.sh
@@ -56,13 +56,13 @@ get_kdump_confs()
                         FAILURE_ACTION="kdump_emergency_shell"
                     ;;
                     reboot)
-                        FAILURE_ACTION="systemctl reboot -f"
+                        FAILURE_ACTION="systemctl reboot -f && exit"
                     ;;
                     halt)
-                        FAILURE_ACTION="halt"
+                        FAILURE_ACTION="halt && exit"
                     ;;
                     poweroff)
-                        FAILURE_ACTION="systemctl poweroff -f"
+                        FAILURE_ACTION="systemctl poweroff -f && exit"
                     ;;
                     dump_to_rootfs)
                         FAILURE_ACTION="dump_to_rootfs"

[PATCH] kdump-lib-initramfs.sh: use -f option for failure_action halt

[piliu]

On 10/30/2019 02:59 PM, Kairui Song wrote:
> On Wed, Oct 30, 2019 at 12:11 PM piliu  wrote:
> > On 10/30/2019 10:57 AM, Kairui Song wrote:
> > > On Wed, Oct 30, 2019 at 9:02 AM [e-mail]
> > >  wrote:
> > > > > -----Original Message-----
> > > > > From: Kairui Song [mailto:[e-mail]]
> > > > > Sent: Monday, October 28, 2019 5:29 PM
> > > > > To: Hatayama, Daisuke/畑山 大輔 
> > > > > Subject: Re: [PATCH] kdump-lib-initramfs.sh: use -f option for failure_action
> > > > > halt
> > > > >
> > > > > On Mon, Oct 28, 2019 at 11:29 AM [e-mail]
> > > > >  wrote:
> > > > > > failure_action halt doesn't work well now. This appears to be similar
> > > > > > to the previous issues such as
> > > > > > b2534348199ad5010c86890a068653d970c9933d and
> > > > > > 89565289c64aa5323278cf5722c725a58b369af8.
> > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks for the patch, it looks good to me in general, but can you add
> > > > > more detail about the problem you are trying to solve?
> > > > > Eg, add some word about the system behavior or some error logs. Like
> > > > > in the two commits you mentioned.
> > > >
> > > > I see. I'll reflect your comment in the next version.
> > > >
> > > > I would write that there is a message indicating halt command is executed
> > > > but actually system is reboot, not halted together with log message.
> > > >
> > > > Also I a little more looked into the behavior using debug message
> > > > with systemd.log-leve=debug. It looks that systemd-halt.service
> > > > is once pulled-in but it is somehow not executed and finally system
> > > > is rebooted.
> > > >
> > > > systemd-udevd-control.socket: Changed listening -> dead
> > > > systemd-udevd-control.socket: Job 100 systemd-udevd-control.socket/stop finished, result=done
> > > >
> > > > [^[[0;32m  OK  ^[[0m] Closed ^[[0;1;39mudev Control Socket^[[0m.
> > > > Kdump: Executing failure action halt
> > > >
> > > > ^-- failure_action halt is executed
> > > >
> > > > Bus private-bus-connection: changing state UNSET → OPENING
> > > > Bus private-bus-connection: changing state OPENING → AUTHENTICATING
> > > > Accepted new private connection.
> > > > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > > > Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/\
> > > > a
> > > > halt.target: Trying to enqueue job halt.target/start/replace-irreversibly
> > > >
> > > > ^-- halt.target gets started being pulled-in here
> > > >
> > > > Added job halt.target/start to transaction.
> > > > Pulling in systemd-halt.service/start from halt.target/start
> > > > Added job systemd-halt.service/start to transaction.
> > > > Pulling in shutdown.target/start from systemd-halt.service/start
> > > > Added job shutdown.target/start to transaction.
> > > > Pulling in dracut-cmdline.service/stop from shutdown.target/start
> > > > Added job dracut-cmdline.service/stop to transaction.
> > > > Pulling in cryptsetup.target/stop from shutdown.target/start
> > > > Added job cryptsetup.target/stop to transaction.
> > > > ...<snip>...
> > > > squash-root.mount: squash-root.mount lost dependency After=dev-loop0.device
> > > > squash-root.mount: squash-root.mount lost dependency References=dev-loop0.device
> > > > squash-root.mount: Collecting.
> > > > Child 400 (umount) died (code=exited, status=0/SUCCESS)
> > > > etc.mount: Child 400 belongs to etc.mount.
> > > > etc.mount: Mount process exited, code=exited, status=0/SUCCESS
> > > > etc.mount: Succeeded.
> > > > etc.mount: Changed unmounting -> dead
> > > > etc.mount: Job 181 etc.mount/stop finished, result=done
> > > > [^[[0;32m  OK  ^[[0m] Unmounted ^[[0;1;39m/etc^[[0m.
> > > > etc.mount: Collecting.
> > > > Received SIGCHLD from PID 400 (n/a).
> > > > inotify event for /etc/localtime
> > > > Failed to stat /etc/localtime, ignoring: No such file or directory
> > > > /etc/localtime doesn't exist yet, watching /etc instead.
> > > > Timezone has been changed (now: UTC).
> > > > Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
> > > > Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/aO\
> > > > perating on architecture: x86-64
> > > >
> > > > Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
> > > > Shutting down.
> > > > Bus private-bus-connection: changing state RUNNING → CLOSING
> > > > dev-vda.device: Failed to send unit remove signal for dev-vda.device: Connection reset by peer
> > > > systemd-journald.service: Executing: /usr/lib/systemd/systemd-journald
> > > > Bus private-bus-connection: changing state CLOSING → CLOSED
> > > > [   15.956995] Unregister pv shared memory for cpu 0
> > > > [   15.967559] reboot: Restarting system
> > > > [   15.970216] reboot: machine restart
> > > >
> > > > ^---- but finally system gets restarted.
> > > >
> > > > This behavior doesn't change even if I changed ExecStart=/usr/bin/systemctl --force halt
> > > > in systemd-halt.service into ExecStart=/usr/bin/systemctl --force --force halt.
> > > > systemctl halt with --force twice means systemctl calls immediately directly reboot
> > > > system call. Thus, I think systemd somehow reboot system before entering systemd-halt.service.
> > >
> > > Thanks, I remember Pingfan have encountered similar problem before,
> > > that force shutdown turns into reboot and that seems to be a systemd
> > > bug. CC Pingfan see if he has any idea about this.
> >
> > Yes, you can refer to commit 89565289c64aa5323278cf5722c725a58b369af8
> > kdump-lib-initramfs.sh: using -force option when poweroff
> >
> > It is a systemd flaw
> > > But it's very strange that systemctl --force --force halt doesn't work
> > > either. I can reproduce this locally with Fedora.
> > >
> > > Also add the missing [e-mail] in CC list.
>
> Hi Pingfan, Dave, Hatayama
>
> How do you think about some changes like this? Maybe it's time to stop
> doing final action if failure action is shutdown/reboot/halt.
> I did some simple test and it seems worked well.
>
> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
> index c409dce..8530556 100755
> --- a/kdump-lib-initramfs.sh
> +++ b/kdump-lib-initramfs.sh
> @@ -56,13 +56,13 @@ get_kdump_confs()
>                          FAILURE_ACTION="kdump_emergency_shell"
>                      ;;
>                      reboot)
>                    FAILURE_ACTION="systemctl reboot -f"
>                    FAILURE_ACTION="systemctl reboot -f && exit"
>                ;;
>                halt)
>                    FAILURE_ACTION="halt"
>                    FAILURE_ACTION="halt && exit"
>                ;;
>                poweroff)
>                    FAILURE_ACTION="systemctl poweroff -f"
>                    FAILURE_ACTION="systemctl poweroff -f && exit"
>                ;;
>                dump_to_rootfs)
>                    FAILURE_ACTION="dump_to_rootfs"

Sounds reasonable