Closed chrisnovakovic closed 5 years ago
Thanks for the idea - I will implement the cleanup signal as an option, because on both, Windows 10 and Debian, testing and process cleanup becomes very unstable when using SIGTERM
. Maybe this is different when using a headful Chrome, but in my environments this is not suitable.
Thank you!
On Linuxish OSes, SIGTERM
works - the problems were in my test setup (mixing TCP sockets and parallel test runs). For Windows, I've set the default to SIGKILL
in b8c745dbe585c6ca323d9ffda209ec4b96b80529 .
This is now on its way onto CPAN as version 0.36.
Stopping Chrome processes launched by WMC using
SIGKILL
is quite extreme: Chrome responds toSIGTERM
, which has the added benefit of giving Chrome a chance to save its state and exit cleanly. There are also situations where sendingSIGKILL
causes quite a mess: I'm driving a copy of Chrome with extensions installed (thus preventing me from using headless mode), so I've written a small wrapper script that starts an Xvfb followed by Chrome, and also traps various exit signals and relays them to Xvfb and Chrome so everything gets cleaned up correctly. I then launch the wrapper script using WMC. When the WMC object gets destroyed, sendingSIGKILL
to my wrapper script causes both Xvfb and Chrome to be orphaned and adopted by init, preventing WMC from working again until Chrome is killed manually (because the old Chrome process is still listening on port 9222), not to mention consuming large amounts of resources in the meantime.This PR changes WMC so that it sends
SIGTERM
to close Chrome rather thanSIGKILL
. It ought to be sensible for most use cases, since Chrome has rarely (if ever) failed to respond toSIGTERM
in my experience. If this isn't preferable for any reason, it'd still be nice to be able to make the signal configurable (e.g. in the WMC constructor).