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

webkit_server failed to start #96

Open
wioux opened this issue Sep 21, 2016 · 0 comments
Open

webkit_server failed to start #96

wioux opened this issue Sep 21, 2016 · 0 comments

Comments

@wioux
Copy link
Member

wioux commented Sep 21, 2016

We shutdown the webkit process by issuing Process.kill(3, pid). SIGQUIT does not always have an immediate effect and we don't waitpid to be sure the process has stopped, which makes it possible that multiple webkit processes can be running at once if we launch a new one before the quit signal has done its job.

Experimenting in my local environment, I've found that the webkit driver will eventually fail to start if there are too many (200+) instances already running:

irb(main):001:0> 275.times{ session = Capybara::Session.new(:webkit); session.evaluate_script("1+1") }
Capybara::Webkit::ConnectionError: /usr/local/bundle/gems/capybara-webkit-1.7.1/bin/webkit_server failed to start.

This issue seems to come up in practice, since in our error queue we have a significant number of jobs which failed with this error:

irb(main):003:0> Delayed::Job.where("last_error LIKE ?", "%webkit_server failed to start%").count
=> 5127

One approach to fixing this would be to waitpid after issuing the SIGQUIT to the webkit process. That would probably get the job done, but since our webkit shutdown logic is already pretty hacky it might be worth looking at whether we can use just a single instance of the webkit driver and reset it between uses.

I have a branch showing that here which I can PR if it seems reasonable.

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

1 participant