From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: "Murilo Opsfelder Araújo" <muriloo@linux.ibm.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
pbonzini@redhat.com, qemu-devel@nongnu.org, david@redhat.com,
cohuck@redhat.com, thuth@redhat.com, borntraeger@de.ibm.com,
frankja@linux.ibm.com, fiuczy@linux.ibm.com, pasic@linux.ibm.com,
alex.bennee@linaro.org, armbru@redhat.com
Subject: Re: [PATCH v3 1/1] os-posix: asynchronous teardown for shutdown on Linux
Date: Fri, 12 Aug 2022 13:45:27 +0200 [thread overview]
Message-ID: <20220812134527.70391185@p-imbrenda> (raw)
In-Reply-To: <fcc03c35-d2c6-a124-d9d0-958056476f20@linux.ibm.com>
On Fri, 12 Aug 2022 08:38:59 -0300
Murilo Opsfelder Araújo <muriloo@linux.ibm.com> wrote:
> On 8/12/22 04:26, Claudio Imbrenda wrote:
> > On Thu, 11 Aug 2022 23:05:52 -0300
> > Murilo Opsfelder Araújo <muriloo@linux.ibm.com> wrote:
> >
> >> On 8/11/22 11:02, Daniel P. Berrangé wrote:
> >> [...]
> >>>>> Hmm, I was hoping you could just use SIGKILL to guarantee that this
> >>>>> gets killed off. Is SIGKILL delivered too soon to allow for the
> >>>>> main QEMU process to have exited quickly ?
> >>>>
> >>>> yes, I tried. qemu has not finished exiting when the signal is
> >>>> delivered, the cleanup process dies before qemu, which defeats the
> >>>> purpose
> >>>
> >>> Ok, too bad.
> >>>
> >>>>> If so I wonder what happens when systemd just delivers SIGKILL to
> >>>>> all processes in the cgroup - I'm not sure there's a guarantee it
> >>>>> will SIGKILL the main qemu before it SIGKILLs this helper
> >>>>
> >>>> I'm afraid in that case there is no guarantee.
> >>>>
> >>>> for what it's worth, both virsh shutdown and destroy seem to do things
> >>>> properly.
> >>>
> >>> Hmm, probably because libvirt tells QEMU to exit before systemd comes
> >>> along and tells everything in the cgroup to die with SIGKILL.
> >>
> >> It seems Libvirt sends SIGKILL if qemu process doesn't terminate within 10
> >> seconds after Libvirt sent SIGTERM:
> >>
> >> https://gitlab.com/libvirt/libvirt/-/blob/0615df084ec9996b5df88d6a1b59c557e22f3a12/src/util/virprocess.c#L375
> >
> > but this is fine.
> >
> > with asynchronous teardown, qemu will exit almost immediately when
> > receiving SIGTERM, and the cleanup process will start cleaning up.
>
> Under normal and orderly conditions, yes.
>
> >> So I guess this patch happened to work with Libvirt because the main qemu
> >> process terminated before the timeout and before SIGKILL was delivered.
> >
> > it seems so
> >
> >>
> >> The cleanup process is trying to solve the problem where the main qemu process
> >> takes too long to terminate. However, if the cleanup process itself takes too
> >> long, SIGKILL will be sent by Libvirt anyway.
> >
> > but that is not a problem, the sole purpose of the cleanup process is
> > to terminate _after_ qemu. it doesn't matter what happens after qemu
> > has terminated. if you look at the patch, after going to great lengths
> > to assure that qemu has terminated, all the child process does is
> > _exit(0).
> >
> >>
> >> Perhaps we can describe this situation in the parameter help, e.g.: If
> >> management layer decides to send SIGKILL (e.g.: due to timeout or deliberate
> >> decision), the cleanup process can exit before the main process, deceiving its
> >> purpose.
> >
> > if the management layer (or the user) decides to send SIGKILL
> > immediately to the whole cgroup without sending SIGTERM first, then
> > this whole asynchronous teardown mechanism is defeated, yes.
>
> This situation is what we likely want to describe in the parameter help. I don't
> want to give users the false impression that this option will *always* behave
> the manner we expect it to work *most* of the time.
fair enough, I'll improve the documentation
>
> --
> Murilo
next prev parent reply other threads:[~2022-08-12 12:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 6:40 [PATCH v3 1/1] os-posix: asynchronous teardown for shutdown on Linux Claudio Imbrenda
2022-08-10 20:30 ` Murilo Opsfelder Araújo
2022-08-11 12:03 ` Claudio Imbrenda
2022-08-11 12:27 ` Daniel P. Berrangé
2022-08-11 13:54 ` Christian Borntraeger
2022-08-11 13:56 ` Claudio Imbrenda
2022-08-11 14:02 ` Daniel P. Berrangé
2022-08-12 2:05 ` Murilo Opsfelder Araújo
2022-08-12 7:26 ` Claudio Imbrenda
2022-08-12 11:38 ` Murilo Opsfelder Araújo
2022-08-12 11:45 ` Claudio Imbrenda [this message]
2022-08-23 17:09 ` Daniel P. Berrangé
2022-08-30 6:32 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220812134527.70391185@p-imbrenda \
--to=imbrenda@linux.ibm.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=fiuczy@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=muriloo@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).