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@xxxxxxxxxx> --- src/util/virprocess.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Attachment:
signature.asc
Description: PGP signature
