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(a)redhat.com>
---
src/util/virprocess.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)