Skip to content
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

revise taskkill procedure on windows #267

Merged
merged 37 commits into from
May 31, 2022
Merged

revise taskkill procedure on windows #267

merged 37 commits into from
May 31, 2022

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented May 30, 2022

mostly fixes #266

adopted much of playwright's logic (detailed here)

  • chrome process not detached on windows
  • taskkill is done spawnsync instead of execsync. shell:true swapped in for stdio:pipe
  • no chance of rejection in kill() matching pptr & pw behavior.

also:

  • dropped our LH smoke retries to ZERO so the failures are loud and clear
  • rename this.chrome to this.chromeProc (sorry for the noise, but we have another chrome in the public API that's a different thing)

(currently on top of #265 ... lighthouse-smoke...adopt-pw-kill )

@paulirish paulirish requested a review from adamraine May 31, 2022 17:33
}
}
} catch (err) {
const message = `Chrome could not be killed ${err.message}`;
log.warn('ChromeLauncher', message);
reject(new Error(message));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The smoke tests still pass even with this rejection right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no they don't.

removing this rejection is deliberate actually. as mentioned in #266, pptr and pw deliberately do not reject in this case.

and i've been convinced that this is reasonable. there appears to be a race condition and taskkill is attempting to kill processes that are already gone. what's interesting is that when this happens. the processes that fail to be killed (cuz they're not found) are all child proc of the primary chrome proc. the chrome proc is always successfully killed.

take a peek at the SO item linked in microsoft/playwright#7500 .... PW used this MEMUSAGE hack for a while but then determined it wasnt needed. so i'm following their latest pattern.

i think it's still important we have some visibility on when taskkill returns an error, but it's not a fatal situation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They removed it because

Since then, we no longer inherit stdout/stderr, so the error message
should not appear anymore.

Which we also do not do so lgtm.

if (this.chrome) {
log.log('ChromeLauncher', `Chrome already running with pid ${this.chrome.pid}.`);
return this.chrome.pid;
if (this.chromeProc) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: chromeProcess

I'm reading "chromeProc" as "chromeProcedure" (because that is a weird/old way to shorten that word) so reading was confusing

@paulirish paulirish merged commit 3561350 into master May 31, 2022
@paulirish paulirish deleted the adopt-pw-kill branch May 31, 2022 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unreliable process killing on windows
3 participants