[libvirt PATCH 2/2] util: fix success return for virProcessKillPainfullyDelay()

[Ján Tomko]

On a Friday in 2023, Jonathon Jongsma wrote:
>virProcessKillPainfullyDelay() currently almost always returns 1 or -1,
>even though the documentation indicates that it should return 0 if the
>process was terminated gracefully. The only case that it currently
>returns 0 is when it is called with the pid of a process that does not
>exist.
>

All of the callers either check if the return value is less than zero,
ignore it completely, or pass it up higher where one of the first two
options happens.

The return value was only used by virBhyveProcessStop until 2016:
commit c35c2fe78eb05f9becf848393912e0d7ded70da2
     bhyve: drop virProcessKillPainfully() from destroy

I think we can just return 0 and drop the distinction from the function
documentation.

Jano

>This function initially sends a SIGTERM signal to the process. If
>the signal was sent successfully (i.e. virProcessKill() returns 0) we
>immediately sleep for 200ms before iterating the loop. On the second
>iteration of the loop, signum will be set to 0 and we call
>virProcessKill() again to check whether the process still exists. If the
>process does not exist (virProcessKill() returns -1 and errno is ESRCH),
>we consider the process killed successfully. But in order to determine
>what value to return from the function, we compare the value of signum
>to SIGTERM. But signum has already been set to 0; it will only ever be
>SIGTERM in the very first loop iteration. So it always indicates a
>forcible killing even when it is killed gracefully.
>
>Signed-off-by: Jonathon Jongsma <jjongsma at redhat.com>
>---
> src/util/virprocess.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20230925/aa5144af/attachment.sig>