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

[Feature] Send SIGTERM instead of immediate SIGKILL to webServer child process #20705

Closed
domvo opened this issue Feb 7, 2023 · 2 comments
Closed

Comments

@domvo
Copy link

domvo commented Feb 7, 2023

Referencing #18209.

It is best practice to not simply kill (with KILL signal) processes. The problem is that SIGKILL cannot be intercepted trapped and therefore can lead to dangling/zombie processes.

In my specific scenario I spawn three processes with the webServer command in the playwright config:

  1. A fresh database instance using docker compose
  2. The backend
  3. The frontend

The docker compose is started through a little node script with childProcess.exec(). Now, when this node script is killed, the child process (docker compose) is still running, which leads to a zombie container. The same would happen if I ran the docker compose command directly as the webServer command, because docker compose also "expects" a SIGTERM and not a SIGKILL.

Global teardown is not an option here, because I want to give the developers the possibility to start the "webserver" manually before running and creating new tests. If I kill the server in the teardown it is always killed, no matter if it was started by playwright or by hand.

This whole thing was already tackled in the past but lead to unexpected behavior and the "fix" was reverted. See #18865. That means that the initial problem still remains unfixed.

@mxschmitt
Copy link
Member

I reopened the original issue instead of keeping this one.

#18209

@domvo
Copy link
Author

domvo commented Feb 7, 2023

Thank you

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

No branches or pull requests

2 participants