-
Notifications
You must be signed in to change notification settings - Fork 96
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
Comments
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. |
Like the GitHub Actions workflow job cleanup of orphaned processes suggested, chrome processes do not seem to be closed after chromedriver closes. |
Ok, so I got a tip! Removing the chromedriver |
--no-sandbox
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
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
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
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
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.
The text was updated successfully, but these errors were encountered: