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

windows chromedriver leaves orphan chrome processes when using --no-sandbox #572

Closed
lread opened this issue May 3, 2024 · 3 comments · Fixed by #576
Closed

windows chromedriver leaves orphan chrome processes when using --no-sandbox #572

lread opened this issue May 3, 2024 · 3 comments · Fixed by #576

Comments

@lread
Copy link
Collaborator

lread commented May 3, 2024

Gonna assume the GitHub Actions windows image runner has some issue with chrome/chromedriver.

See some notes here: #571 (comment)

Runner image where problem exhibits: https://github.com/actions/runner-images/releases/tag/win22%2F20240421.1

The GitHub Actions team releases new versions of image runners every week (or two?). We'll see what results the next runner brings us.

@lread lread pinned this issue May 3, 2024
@lread
Copy link
Collaborator Author

lread commented May 12, 2024

Ok. I got tired of the long-running then failing Windows/chrome situation and hacked the windows image-runner to run install chrome and chromedriver current versions just like the GitHub actions team does in PR #574. I expected this would work, but the newer versions of chrome/chromedriver exhibit the same failing symptoms.

One thing that is a bit odd is that the Windows image-runner installs chrome and chromedriver from separate sources. Google encourages folks to install both from Chrome for Testing. But there seems to have been problems with that initially actions/runner-images#8114, so GitHub reverted to installing Chrome via the normal user (enterprise) installer.

Google states that it is important that the chromedriver version matches the chrome version.
Installing from two separate sources means that this has not been the case. A matching chromedriver version is not always available.

@lread
Copy link
Collaborator Author

lread commented May 12, 2024

Like the GitHub Actions workflow job cleanup of orphaned processes suggested, chrome processes do not seem to be closed after chromedriver closes.

@lread
Copy link
Collaborator Author

lread commented May 13, 2024

Ok, so I got a tip! Removing the chromedriver --no-sandbox option resolves the orphan chrome processes issue on Windows.

@lread lread changed the title ci: windows/chrome is broken windows chromedriver leaves orphan chrome processes when using --no-sandbox May 14, 2024
lread added a commit that referenced this issue May 14, 2024
Our tests included the `--no-sandbox` option for chrome.

This seems to have been harmless until recently.
On Windows, it now results in orphaned chrome processes which results in
tests bogging and then, after a long, while failing.

Removing `--no-sandbox` when running on Windows resolves the issue.

The `--no-sandbox` option allows testing under a root user.
Because we don't run tests under root on any OS or environment,
I feel comfortable removing `--no-sandbox` across all OS testing.

This change also includes new bb task `ps`, a bare-bones cross-platform
way to report on running processes. This was useful while diagnosing the
issue so I've left it in.

I also switched from `babashka.process/destroy` to
`babashka.process/destroy-tree` when killing a web driver process.
This did not help with the Windows chrome orphan issue, but I expect it
is generally a better way to go.

Closes #572
lread added a commit that referenced this issue May 14, 2024
Our tests included the `--no-sandbox` option for chrome.

This seems to have been harmless until recently.
On Windows, it now results in orphaned chrome processes which results in
tests bogging and then, after a long, while failing.

Removing `--no-sandbox` when running on Windows resolves the issue.

The `--no-sandbox` option allows testing under a root user.
Because we don't run tests under root on any OS or environment,
I feel comfortable removing `--no-sandbox` across all OS testing.

This change also includes new bb task `ps`, a bare-bones cross-platform
way to report on running processes. This was useful while diagnosing the
issue so I've left it in.

I also switched from `babashka.process/destroy` to
`babashka.process/destroy-tree` when killing a web driver process.
This did not help with the Windows chrome orphan issue, but I expect it
is generally a better way to go.

Closes #572
lread added a commit that referenced this issue May 14, 2024
Our tests included the `--no-sandbox` option for chrome.

This seems to have been harmless until recently.
On Windows, it now results in orphaned chrome processes which results in
tests bogging and then, after a long, while failing.

Removing `--no-sandbox` when running on Windows resolves the issue.

The `--no-sandbox` option allows testing under a root user.
Because we don't run tests under root on any OS or environment,
I feel comfortable removing `--no-sandbox` across all OS testing.

This change also includes new bb task `ps`, a bare-bones cross-platform
way to report on running processes. This was useful while diagnosing the
issue so I've left it in.

I also switched from `babashka.process/destroy` to
`babashka.process/destroy-tree` when killing a web driver process.
This did not help with the Windows chrome orphan issue, but I expect it
is generally a better way to go.

Closes #572
lread added a commit that referenced this issue May 14, 2024
Our tests included the `--no-sandbox` option for chrome.

This seems to have been harmless until recently.
On Windows, it now results in orphaned chrome processes which results in
tests bogging and then, after a long, while failing.

Removing `--no-sandbox` when running on Windows resolves the issue.

The `--no-sandbox` option allows testing under a root user.
Because we don't run tests under root on any OS or environment,
I feel comfortable removing `--no-sandbox` across all OS testing.

This change also includes new bb task `ps`, a bare-bones cross-platform
way to report on running processes. This was useful while diagnosing the
issue so I've left it in.

I also switched from `babashka.process/destroy` to
`babashka.process/destroy-tree` when killing a web driver process.
This did not help with the Windows chrome orphan issue, but I expect it
is generally a better way to go.

Closes #572
@lread lread unpinned this issue May 15, 2024
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 a pull request may close this issue.

1 participant