PhantomJS disconnecting because no message in 10000 ms when set to single-run #126
Comments
|
Try to set karma's browserNoActivityTimeout setting, that worked for me: https://github.com/karma-runner/karma/blob/master/docs/config/01-configuration-file.md#browsernoactivitytimeout |
|
@u-nikos thanks for the suggestion. I'll give it a try when I'm back next week. |
|
Any luck? There's several issues raised around this. Most solutions seem to land on bump the retry count + timeout. Wonder if this related to IPv6, as all the machines I've seen this on have localhost resolve to |
|
@zsims, thanks for the bump. I increased the timeout to 30 seconds and the issue persists. localhost does resolve to |
|
browserDisconnectTolerance will cause it to attempt to reconnect, which is better than a timeout. Though your log is indicating something else. |
|
I just had the same problem. It only occured on my continous integration server while working fine locally. I tried to increase the browserNoActivityTimeout but still no tests ran. I finally fixed this by removing the plugins property from my karma config. |
|
Had the same issue today - worked locally on mac OSX sierra but ran into the error on our CI server (redhat) @chrstnbrn's suggestion fixed the problem for us |
|
@chrstnbrn thanks for the suggestion, but we already don't have a plugins section in our config, neither when running locally or on our CI server. |
|
Using Chrome instead of Phantom JS was the only way I was able to resolve this. |
|
I have a similar issue which just started occurring today. The tests start to run but then after a certain number of tests (it always looks to be around the same number) I get the All tests ran successfully a couple of days ago and haven't changed since. It doesn't look like I'm running out of memory and I do have swap enabled. |
|
Running into a similar issue on our build agent on VSTS. We have a couple of retries, but it disconnects every time. We added the following properties to the config file: |
|
I had a similar issue on Windows 10, nodejs 4.6.1, karma 1.1.2, phantomjs-prebuilt: 2.1.8. I fixed it by changing my karma config preprocessors option from: TO |
|
@alex7egli thanks for the suggestion. I checked, we aren't using any preprocessors. |
|
I'm also having this problem. Excluding bower_components and jspm_packages didn't help. Strangely enough, if I pass |
|
We are having the same issue running tests in Chrome on VSTS: 2016-12-19T17:29:42.4047493Z �[36m19 12 2016 17:29:42.404:DEBUG [Chrome 50.0.2661 (Windows 10 0.0.0)]: �[39mDisconnected during run, waiting 2000ms for reconnecting. timeouts are set in karma.conf.js to: preprocessors are set to check only .js files in the app, any suggestions ? |
|
I have the same problem with Appveyor, but not on my mac. |
|
Same here: Anyone made any progress on that? |
|
@zeevm exactly. You explained in a better way my problem XD |
|
Going deeper I've enabled all debugging options available and the scenario is always the same, karma serves all files to PhantomJS up to karma-test-shim.js and then the process gets stuck, I assume the browser stops responding and karma disconnects it after 10 seconds. |
|
I still get the issue ("Disconnected (1 times), because no message in 10000 ms") after trying the following:
Using phantomjs: 2.1.1 and karma-phantomjs-launcher: 1.0.0 I noticed that when I skipped a large chunk of tests they did run. It's not failing on a particular test my theory now it has something to do with the amount. Any suggestions what I can try? Tweak my VM perhaps? |
|
I managed to fix my issue by increasing the timeout of mocha. Hopefully this helps someone else! eg. |
|
I still get the issue also with an higher timeout |
|
Just started having this same problem last week: phantomjs 2.1.1, karma 1.3.0, karma-phantomjs-launcher 1.0.0. I've tried most of the suggestions here, nothing has helped yet. Works fine on my mac, fails with the timeout message on our linux/Jenkins build system. |
|
I was also running into this issue, and I discovered it was because I was (for some reason) missing the entry for localhost in my /etc/hosts file, which PhantomJS uses when it runs. I added 127.0.0.1 localhost to my /etc/hosts, and it fixed this problem for me. |
|
Short term fix as i'm also experiencing this issue, but try changing the port number you are using your karma tests on. config.set ({
port: 9876
});I put mine to 9877 until it stopped working and then to 9878. |
|
Changing the settings fixes the issue for a short period. |
|
@iheartpaypal my hosts file already has entries for both 127.0.0.1 and ::1 @ErikSchierboom i tried the |
|
Hi I am getting the same issue with Chrome and Karma. Chrome 55.0.2883 (Windows 10 0.0.0): Executed 0 of 0�[31m DISCONNECTED�[39m (16 mins 42.766 secs / 0 secs) My config settings are: Execute Karma from command prompt: I do not have any plugin statement. |
|
@rupendra-sharma @androticus are you guys using ui-router? What my issue was that ui-router had updated to (1.0.0-rc.1) when doing an npm install and the tests started failing out. I then switched back to the previous version of ui-router and everything runs perfect again. I hope this helps anyone else that runs into the same issue. I spent a lot of time tracking this down hahah |
|
No, the retry is about connecting, doesn't have to do with browser crash. Karma will relaunch if the browser crashes. |
|
the only thing that helped me was fixing karma version to 1.5.0 (I'm using Visual Studio Online CI) |
|
Any update on this? |
|
I've had this issue too. Tried different versions and browsers like |
|
Still an issue for me. Compared to Chrome, Firefox or any other browser phantomjs is just super super slow. |
|
Not really an issue if you use headless Chrome: module.exports = function (config) {
config.set({
//...
customLaunchers: {
ChromeHeadless: {
base: 'Chrome',
flags: [
'--headless',
'--disable-gpu',
'--no-sandbox',
// Without a remote debugging port, Google Chrome exits immediately.
'--remote-debugging-port=9222'
]
}
},
//...
browsers: ['ChromeHeadless'],
//...
});
}; |
|
this has started happening to my builds more and more in the past few weeks. It's on phantomjs and puppeteer. |
|
Also facing the same issue on our Jenkins CI server. Tests run fine locally, but fail on Jenkins CI server sometimes, with the message Executed 0 of 0 DISCONNECTED for some browsers (most of the time Chrome and IE). Failures seem to appear when we spend a "long" time since the last tests run, like some hours... |
|
I suffered from these timeout issues for a long time in my Angular app with CLI. I always had to increase the following 2 timeout values: test.ts karma.conf.js Finally thanks for this blog post I replaced Karma with Jest. It is blazing fast!
|
|
Sadly seems so. I've recently discovered Jest myself. |
|
basically same issue for us too: [web-server]: 404: _karma_webpack_/1.bundle.js
ERROR [launcher]: PhantomJS crashed.
WARN [PhantomJS 2.1.1 (Linux 0.0.0)]: Disconnected (1 times), because no message in 10000 ms.
PhantomJS 2.1.1 (Linux 0.0.0) ERROR
Disconnected, because no message in 10000 ms.
PhantomJS 2.1.1 (Linux 0.0.0) ERROR
Disconnected, because no message in 10000 ms.
PhantomJS 2.1.1 (Linux 0.0.0): Executed 0 of 29 DISCONNECTED (10.486 secs / 0 secs)
FAILURE UNRELATED TO TESTS
More info:
{
success: 0,
failed: 0,
error: false,
disconnected: true,
exitCode: 1
}Our solution was just to add an entry to our with To be honest, I'm not sure what changed in |
|
I ended up moving to Jest too. |
|
So in hope this will help someone, I encountered this error importing Vuex getters with the mapGetters utility which were not used in the component (though they were used through other imported getters, not sure if relevant). |
On low-horsepower CI systems karma frequently times out waiting for phantomjs. We see this in our Travis-CI runs. Users also see it: karma-runner/karma-phantomjs-launcher#126.
On low-horsepower CI systems karma frequently times out waiting for phantomjs. We see this in our Travis-CI runs. Users also see it: karma-runner/karma-phantomjs-launcher#126.
On low-horsepower CI systems karma frequently times out waiting for phantomjs. We see this in our Travis-CI runs. Users also see it: karma-runner/karma-phantomjs-launcher#126.
|
TLDR; Angular component with @font-face block in scss file caused PhantomJS to disconnect. Solved by moving all @font-face blocks to a single file which is imported only once in the global scss file, NOT in the component scss files. Not the issue The issue returned. |
|
In my case, it was not enough free memory on the server. I found it after increasing those parameters I got message Killed and code error 137 afterwards. |
|
For those still having this problem it appears to be a combination of these 4 libraries, and different versions not working together:
Here is the combination of libraries and version that fixed this for me:
Hope this helps others 🍻 |
|
I had this problem without jasmine |
|
@graingert - it's most likely related to Karma and the karma-chrome-launcher library then (assuming you are using Chrome and Karma as your test runner). |
Probably the additional configs help to prevent the timeout issues in the unit test: karma-runner/karma-phantomjs-launcher#126
When running tests on our build servers on random runs, seemingly, no tests run and karma exits with the message:
So far I've only been able to reproduce this when using the
--single-runoption and only on our build servers, on my dev box I've never experienced this. Here's the version info on the servers:Windows 2012 R2
node: v4.4.5
karma: v0.13.22
karma-phantomjs-launcher: 1.0.0
phantomjs-prebuilt: 2.1.7
PhantomJS: 2.1.1
On one build server it seems the tests run about 50% of the time, on the other server it's less than 10%. Also, if I set
log-level=debugthen it raises the percentage to successfully running over 90% of the time on both servers. Here's the debug info from a failed run (with names stripped):If I change the karma config on the build servers to use Chrome then the tests always run successfully. I've tried previous versions of karma-phantomjs-launcher and phantomjs-prebuilt, but I haven't noticed a difference. I'm not sure where to go from here.
The text was updated successfully, but these errors were encountered: