-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Fix unit test failures for TestTryKillOne #21426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -73,6 +73,20 @@ func Exists(pid int, executable string) (bool, error) { | |
return entry.Executable() == executable, nil | ||
} | ||
|
||
// ExistsPID reports whether a process with the given pid exists. | ||
// This is a PID-only check (no executable name matching). | ||
func ExistsPID(pid int) (bool, error) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When do we call this? if we have a child process we know that the pid exist and we don't need to look it up since the pid cannot be reused until we wait() for the child. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would call this PIDExist() - since it is a little bit confusing with Exists() which is about a process, using a pidfile. We already have a function pidExists() so this function can simply expose it, or we can renamse pidExists() to PIDExists() to make it useful outside of the package. |
||
if pid <= 0 { | ||
return false, nil | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This check seems unneeded - why would you call with invalid pid? |
||
|
||
entry, err := ps.FindProcess(pid) | ||
if err != nil { | ||
return true, err | ||
} | ||
return entry != nil, nil | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is incorrect - we have pidExist() helper that does the right thing on windows and posix. |
||
} | ||
|
||
// Terminate a process with pid and matching name. Returns os.ErrProcessDone if | ||
// the process does not exist, or nil if termination was requested. Caller need | ||
// to wait until the process disappears. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sending SIGKILL (or any other signal is asynchronous. It can return before the process was killed.
So checking if the pid exist in the processes table is racy and incorrect. The way to check the process status and detect if it was killed is to wait() for the process:
https://pkg.go.dev/os#Process.Wait
and get the system dependent exist status:
https://pkg.go.dev/os#ProcessState.Sys
On posix we can get check if the process was terminated by signal and get the signal from
https://pkg.go.dev/syscall#WaitStatus
In process_test.go we test Kill() little differently:
We don't verify the exit status since our test process can be configured to block SIGTERM, and we know that the only reason for termination can be SIGKILL.
If we need ugly platform specific code to check the exit status we can put it in the process package to make this easy to use everywhere. The package already have build tags to make it easy to do the right thing on windows and other platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current change,
I've avoided adding any platform-dependent code checks for exit status to make a short and clean change.
any thoughts, @nirs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Waiting on for Wait() with t timeout looks correct and better than the way we do this in process_test.go, since we know we will stop waiting on timeout. I'm not sure the wait is intrrupted in current code in process_test.go.
The check for pid exists seems unneeded - if the the wait completed we know the process terminated so there is nothing to check. And if there is nothing to check there is no need to add the process.ExistPID().
I agree that we don't have to verify that the process was terminated by signal, but this seems like a useful utility to have.