Re: [Qemu-devel] [PATCH 0/1] add exit-script option to qemu

[Dominik Csapak]

On 10/5/18 10:38 AM, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 08:56:27AM +0200, Dominik Csapak wrote:
> > On 10/4/18 3:51 PM, Daniel P. Berrangé wrote:
> > > On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak wrote:
> > > > this patch aims to execute a script when qemu exits
> > > > so that one can do cleanups when using --daemonize without
> > > > having to use the qmp monitor
> > >
> > > IMHO the idea of cleanup scripts run by QEMU itself is flawed.
> > > QEMU will inevitably crash before cleanup scripts can be run,
> > > so whatever mgmt app is using QEMU needs to be able to do
> > > cleanup without QEMU's help.
> > >
> > > I think this can be done more reliably with a wrapper script,
> > > that spawns QEMU, waits for it to exit and then calls the
> > > cleanup script. On Linux at least you can use prctl() with
> > > PR_SET_CHILD_SUBREAPER so you can detect exit'ing of QEMU
> > > even after it has daemonized.
> > >
> > > Perhaps we could have such a wrapper script put in the
> > > contrib directory
> > >
> > > Regards,
> > > Daniel
> > Hi,
> >
> > for cleaning up after qemu crashes, you are completely right,
> > (ignoring that the downscript for tap devices also never gets executed
> > then), but this series has another use.
> >
> > With it, a user can determine the reason of a graceful shutdown
> > (e.g., if it was by a signal, qmp or from inside) of qemu,
> > especially when using -no-reboot without using qmp
> >
> > and using qmp for that is not very practical for everyone,
> > or is there another way for that which i am missing?
>
> Honestly QMP *is* the right answer. We've put alot of effort into QMP
> and I don't think it is sensible to start adding new mechanisms to
> provide the same information in an adhoc manner.
>
> What makes you think QMP isn't practical to use ?  We have client
> impls that talk to QMP in scripts/qmp that are just a few 100 lines
> of pretty simple python code.

ok, i just found that having to start an extra program waiting for qmp
events might be overkill for some users

nonetheless, i just found out that even with qmp, there is no way
to see if a machine started with '-no-reboot' was trying to reboot
or just shutting down, in both cases i got a SHUTDOWN event
with 'guest: true'

would it make sense to send a patch that introduces a new data field
for the shutdown event that says if it was really a reset?