Error socket hang up docker - Исправление ошибок и поиск оптимальных решений проблем

In this article, we will see some of the solutions to the error “socket hang up” in Docker. At Bobcares, with our Docker Hosting Support Services, we can handle your Docker Hang-up issues.

Error “Socket Hang Up” In Docker

Docker avoids repetitive, tedious config processes and is used across the development lifecycle for quick, simple, and portable app development – desktop and cloud. Its full end-to-end platform comprises UIs, CLIs, APIs, and security that are designed to operate together throughout the whole app delivery lifecycle.

It uses OS-level virtualization to deliver software in packages called containers. It is a small, stand-alone software package that contains everything needed to run an app: code, runtime, system tools, system libraries, and settings.

Here, when the user successfully built and started the Docker container, it is up and running. However, when tried to use it after removing the containers and images and rebuilding it, the following error appears:

Other User Details

Docker File

Container Creation:

# Create Virtual Network
$ sudo docker network create network1 
# Using custom network as there are multiple containers 
# which communicate with each other

# Create Containers
$ sudo docker build -t form_ocr:latest .
$ sudo docker run -d -p 6001:5000 --net network1 --name form_ocr form_ocr

The output of netstat command:

$ netstat -nltp 
...
tcp6 0 0 :::6001 :::* LISTEN -

The output of the Docker container inspect:

$ sudo docker container inspect <container-id>

Output (docker ps output):

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
835e8cb11eee form_ocr "python3 app.py" 16 hours ago Up 40 seconds 0.0.0.0:6001->5000/tcp form_ocr

Multiple Solutions For The Error “Socket Hang Up” In Docker

Solution 1: Simply include the following code in main.ts, where we listen to the port.

await app.listen(6001, '0.0.0.0', ()  => console.log(`Listening on port:  6000`));

Also include the ‘0.0.0.0’, it should work.

Solution 2: Check that the app is listening on 0.0.0.0 inside the container.

Solution 3: Instead of an internet address, try localhost:6001. We can also try any of the system’s local IP addresses, which we can find by typing ifconfig or ipconfig in Linux or Windows, respectively.

[Looking for a solution to another query? We are just a click away.]

Conclusion

The article provides three solutions from our Tech team to fix the error, “socket hang up” in Docker.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

Источник

Hey, I faced this problem recently and managed to solve the issue. I had a back-end A communicating with an API B through axios requests to send emails (using nodemailer) to an SMTP relay. Some requests took longer for «B» to process (2~3 minutes), throwing the socket hang up error in «A». However, «B» still managed to send the email, so I knew something was wrong.

When you create an HTTP(S) server in node, it sets the socket timeout to 0 (no timeout). Nonetheless, the socket still closed and threw a «socket hang up» error; using the keepAlive option from HTTP(S) agent also didn’t work. After looking through dozens of issues, tutorials, questions and stackoverflow, I found something that helped me.

In both servers, I set the socket timeout to 10 * 60 * 1000 (10 minutes) and wrapped the send email handler on «B» inside a 5 minutes timeout. You can choose smaller much values such as 10 and 20 secs, as long as socketTimeout(server) > setTimeout(handler), but you’d also have to consider the time it’d take to execute the handler.

// Servers A and B
https
    .createServer(/*server params go here*/)
    .on('secureConnection', (socket) => {
      // HTTPS: secureConnection
      // HTTP: connection
      socket.setTimeout(10 * 60 * 1000); // 10 minutes
    })
    .listen(port)

// Server B Express.js handler
function sendEmail(req,res) {

/* logic to build email... */
  setTimeout(() => {
    this.transporter.sendMail(email, (err, response) => {
      if (err) {
        return res.status(502).json({ ok: false, message: 'Email not sent' });
      }
        return res.status(200).json({ ok: true, message: 'Email sent' });
    });
  }, 5 * 60 * 1000); // 5 minutes
}

Then, I sent a request from «A» to «B»:

// Server A
function sendEmailToB(email) {

  /* more logic to build email... */
  return new Promise((resolve, reject) => {      
    axios
      .post(endpointB, email)
      .then((result) => resolve(result))
      .catch((err) => reject(err));
  });
}

And alas, the request was a success. No more socket hangup errors!!
I’d like to note that I’m not sure if it’s good to keep the socket open for larger amounts of time, but in our case we needed just a few more seconds to process the requests successfully, so I don’t think it’ll be that bad. As always YMMV, so be careful if adopting this solution.

Hope this helps someone!

Источник

I just started using Postman. I had this error «Error: socket hang up» when I was executing a collection runner. I’ve read a few post regarding socket hang up and it mention about sending a request and there’s no response from the server side and probably timeout. How do I extend the length of time of the request in Postman Collection Runner?

16 Answers

Socket hang up, error is port related error. I am sharing my experience. When you use same port for connecting database, which port is already in use for other service, then «Socket Hang up» error comes out.

eg:- port 6455 is dedicated port for some other service or connection. You cannot use same port (6455) for making a database connection on same server.

Sometimes, this error rises when a client waits for a response for a very long time. This can be resolved using the 202 (Accepted) Http code. This basically means that you will tell the server to start the job you want it to do, and then, every some-time-period check if it has finished the job.

If you are the one who wrote the server, this is relatively easy to implement. If not, check the documentation of the server you’re using.

Postman was giving «Could not get response» «Error: socket hang up».
I solved this problem by adding the Content-Length http header to my request

Are you using nodemon, or some other file-watcher? In my case, I was generating some local files, uploading them, then sending the URL back to my user. Unfortunately nodemon would see the «changes» to the project, and trigger a restart before a response was sent. I ignored the build directories from my file-watcher and solved this issue.

Here is the Nodemon readme on ignoring files: https://github.com/remy/nodemon#ignoring-files

I have just faced the same problem and I fixed it by close my VPN. So I guess that’s a network agent problem. You can check if you have some network proxy is on.

Socket hang up error could be due to the wrong URL of the API you are trying to access in the postman. please check the URL once carefully.

I solved this problem with disconnection my vpn. you should check if there is vpn connected.

this happaned when client wait for response for long time
try to sync your API requests from postman

then make login post and your are done

If Postman doesn’t get response within a specified time it will throw the error «socket hang up».

I was doing something like below to achieve 60 minutes of delay between each scenario in a collection:

get https://postman-echo.com/delay/10
pre request script :-
setTimeout(function(){}, [50000]);

I reduced time duration to 30 seconds:

setTimeout(function(){}, [20000]);

After that I stopped getting this error.

I had the same issue: «Error: socket hang up» when sending a request to store a file and backend logs mentioned a timeout as you described. In my case I was using mongoDB and the real problem was my collection’s array capacity was full. When I cleared the documents in that collection the error was dismissed. Hope this will help someone who faces a similar scenario.

It’s possible there are 2 things, happening at the same time.

The url contains a port which is not commonly used AND
you are using a VPN or proxy that does not support that port.

I had this problem. My server port was 45860 and I was using pSiphon anti-filter VPN. In that condition my Postman reported «connection hang-up» only when server’s reply was an error with status codes bigger than 0. (It was fine when some text was returning from server with no error code.)

When I changed my web service port to 8080 on my server, WOW, it worked! even though pSiphon VPN was connected.

Following on Abhay’s answer: double check the scheme. A server that is secured may disconnect if you call an https endpoint with http.

This happened to me while debugging an ASP.NET Core API running on localhost using the local cert. Took me a while to figure out since it was inside a Postman environment and also it was a Monday.

«Socket Hung Up» can be on-premise issue some time’s, because, of bottle neck in %temp% folder, try to free up the «temp» folder and give a try

I fixed this issue by disabling Postman token header.screenshot

What helped for me was replacing ‘localhost’ in the url to http://127.0.0.1 or whatever other address your local machine has assigned localhost to.

Источник

Pure of heart, life is full of sweet and joy. — Leo Tolstoy

Socket hang up first appeared in a service load test and was later resolved. Recently, this problem was reported again when node.js service migrated to K8S container. After checking the cause, it was found that the container’S CPU and memory size were limited. Here is a summary of what Socket hang up is, when it happens, and how to solve it.

About the author: May Jun, Nodejs Developer, moOCs certified author, love technology, like sharing, welcome to pay attention to Nodejs technology stack and Github open source project www.nodejs.red

What is a Socket hang up

What is a Socket hang up?

Socket hang up means that the socket (link) is hung up. No matter which language you use, you should have encountered it more or less, but have you ever thought about why? For example, in Node.js, the system provides a default timeout of 2 minutes for the HTTP server. If a request exceeds this time, the HTTP server will close the request. When a client tries to return a request and finds that the socket has been «hung up», it sends a socket hang up error.

To understand a problem, or to practice more, the following is a small demo of the problem and then combine with node.js HTTP related source code to further understand Socket hang up? Also recommend that you look at the stack overflow of the universal also has a discussion on the issue above stackoverflow.com/questions/1… .

Replicating Socket hang up

The service side

To start an HTTP service, define the /timeout interface to delay the response for 3 minutes

const http = require('http');
const port = 3020;

const server = http.createServer((request, response) =  {
    console.log('request url: ', request.url);

    if (request.url === '/timeout') {
        setTimeout(function() {
            response.end('OK! ');
        }, 1000 * 60 * 3)
    }
}).listen(port);

console.log('server listening on port ', port);
Copy the code

The client

const http = require('http');
const opts = {
  hostname: '127.0.0.1'.port: 3020.path: '/timeout'.method: 'GET'}; http.get(opts, (res) = {let rawData = ' ';
  res.on('data', (chunk) = { rawData += chunk; });
  res.on('end', () =  {try {
      console.log(rawData);
    } catch (e) {
      console.error(e.message); }}); }).on('error', err = {
  console.error(err);
});
Copy the code

After starting the server and then starting the client about 2 minutes later or directly killing the server, the following error is reported. You can see the corresponding error stack

Error: socket hang up
    at connResetException (internal/errors.js:570:14)
    at Socket.socketOnEnd (_http_client.js:440:23)
    at Socket.emit (events.js:215:7)
    at endReadableNT (_stream_readable.js:1183:12)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  code: 'ECONNRESET'
}
Copy the code

The node.js HTTP client source code does not receive any response, so it is considered that the socket has ended. A connResetException(‘socket hang up’) error is therefore emitted at L440.

// https://github.com/nodejs/node/blob/v12.x/lib/_http_client.js#L440

function socketOnEnd() {
  const socket = this;
  const req = this._httpMessage;
  const parser = this.parser;

  if(! req.res  ! req.socket._hadError) {// If we don't have a response then we know that the socket
    // ended prematurely and we need to emit an error on the request.
    req.socket._hadError = true;
    req.emit('error', connResetException('socket hang up'));
  }
  if (parser) {
    parser.finish();
    freeParser(parser, req, socket);
  }
  socket.destroy();
}
Copy the code

Socket hang up Solution

1. Set the TIMEOUT period of the HTTP Server socket

By default, the timeout value of the server is 2 minutes. If it does, the socket will automatically destroy itself. You can use the server.setTimeout(msecs) method to set the timeout to a larger value. Passing a 0 will turn off the timeout mechanism

// https://github.com/nodejs/node/blob/v12.x/lib/_http_server.js#L348
function Server(options, requestListener) {
  // ...

  this.timeout = kDefaultHttpServerTimeout; // The default value is 2 x 60 x 1000
  this.keepAliveTimeout = 5000;
  this.maxHeadersCount = null;
  this.headersTimeout = 40 * 1000; // 40 seconds
}
Object.setPrototypeOf(Server.prototype, net.Server.prototype);
Object.setPrototypeOf(Server, net.Server);


Server.prototype.setTimeout = function setTimeout(msecs, callback) {
  this.timeout = msecs;
  if (callback)
    this.on('timeout', callback);
  return this;
};
Copy the code

The modified code looks like this:

const server = http.createServer((request, response) =  {
    console.log('request url: ', request.url);

    if (request.url === '/timeout') {
        setTimeout(function() {
            response.end('OK! ');
        }, 1000 * 60 * 3)
    }
}).listen(port);

server.setTimeout(0); // Set the timeout period
Copy the code

If you do not set setTimeout, you can also catch such errors on the HTTP client, put them in the queue and initiate retry. If the probability of such errors is high, you should check whether the corresponding service has abnormal problems such as slow processing.

ECONNRESET VS ETIMEDOUT

Note the difference between ECONNRESET and ETIMEDOUT

ECONNRESET is read timeout. {«code»:»ECONNRESET»} error occurs when the server is too slow to respond properly, such as the socket hang up example described above.

ETIMEDOUT refers to the timeout that occurs when a client initiates a connection with a remote server. Here is an example of a request from the Request module.

const request = require('request');

request({
  url: 'http://127.0.0.1:3020/timeout'.timeout: 5000,
}, (err, response, body) = {
  console.log(err, body);
});
Copy the code

In the above example, {code: ‘ETIMEDOUT’} error is reported after approximately 5 seconds, and the stack is as follows:

Error: ETIMEDOUT
    at Timeout._onTimeout (/Users/test/node_modules/request/request.js:677:15)
    at listOnTimeout (internal/timers.js:531:17)
    at processTimers (internal/timers.js:475:7) {
  code: 'ETIMEDOUT'
}
Copy the code

Источник

Error Socket Hang Up Docker | How To Fix It?

by Shahalamol R | Nov 18, 2022

In this article, we will see some of the solutions to the error “socket hang up” in Docker. At Bobcares, with our Docker Hosting Support Services, we can handle your Docker Hang-up issues.

Error “Socket Hang Up” In Docker

Other User Details

Docker File

Container Creation:

The output of netstat command:

The output of the Docker container inspect:

Output (docker ps output):

Multiple Solutions For The Error “Socket Hang Up” In Docker

Solution 1: Simply include the following code in main.ts, where we listen to the port.

Also include the ‘0.0.0.0’, it should work.

Solution 2: Check that the app is listening on 0.0.0.0 inside the container.

Solution 3: Instead of an internet address, try localhost:6001. We can also try any of the system’s local IP addresses, which we can find by typing ifconfig or ipconfig in Linux or Windows, respectively.

[Looking for a solution to another query? We are just a click away.]

Conclusion

The article provides three solutions from our Tech team to fix the error, “socket hang up” in Docker.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

Socket hang up on long requests #2936

Comments

hnafar commented Apr 29, 2020 •

Describe the bug

When sending a request from inside a docker container to an endpoint that takes a long time before responding (more than 10 muinutes), I get the following error:

setting the timeout on axios does not help. This does not happen when I run the client code directly on my machine, only when it is run inside a docker container.

To Reproduce

create a node server that takes a long time to respond:

Create a node script like below and run it inside a docker container, sending a request to server created above:

Expected behavior

Wait for the response and not throw an error.

Environment:

Axios Version [e.g. 0.19.2]
Docker desktop for windows, node:10 base image

The text was updated successfully, but these errors were encountered:

airtonix commented May 13, 2020

Not the Author or a maintainer, but some things that will get asked are:

version of node you used on your windows workstation
did you use powershell or cmd.exe?
what’s the output of env from powershell or conversly dir env: (you can clean it of sensitive stuff)
can you provide a reproduction repository (like how I do here for a vscode bug: https://github.com/airtonix/vscode-bug-with-remote-containers-and-environment-variables)
- ideally the repro repo should use npm scripts that work on windows and within the docker container (so use things like npm-run-all, onchange, cross-var, cross-env)

padaliya-Kapil commented Dec 6, 2020 •

I’m also getting same issue .
To reproduce
`

<
devconnector: ‘1.0.0’,
npm: ‘6.14.8’,
ares: ‘1.16.1’,
brotli: ‘1.0.9’,
cldr: ‘37.0’,
icu: ‘67.1’,
llhttp: ‘2.1.3’,
modules: ’88’,
napi: ‘7’,
nghttp2: ‘1.41.0’,
node: ‘15.0.1’,
openssl: ‘1.1.1g’,
tz: ‘2020a’,
unicode: ‘13.0’,
uv: ‘1.40.0’,
v8: ‘8.6.395.17-node.15’,
zlib: ‘1.2.11’
>

Whenever I pass ‘username’ that does not exist on github it is throwing Error: socket hang up
It works fine with correct username

JoorgeFerrari commented Jan 26, 2021

Watching issue, looking for fix

cazuzaneto commented Feb 15, 2021

I recently got this Socket hang up problem. I researched for a few days until I found a solution that worked for me. My scenario was different from the one presented above, however, maybe this can help.

It worked for me to add the httpsAgent property with keepAlive: true in creating the http client. Here’s an example of what it might look like:

This property is responsible for managing the sockets for client-side http connections. The justification for using this property can be found here.

I also found an answer on the stackoverflow that also covers the subject, here.
So, I hope this helps.

beecorrea commented Mar 1, 2021 •

Hey, I faced this problem recently and managed to solve the issue. I had a back-end A communicating with an API B through axios requests to send emails (using nodemailer) to an SMTP relay. Some requests took longer for «B» to process (2

3 minutes), throwing the socket hang up error in «A». However, «B» still managed to send the email, so I knew something was wrong.

When you create an HTTP(S) server in node, it sets the socket timeout to 0 (no timeout). Nonetheless, the socket still closed and threw a «socket hang up» error; using the keepAlive option from HTTP(S) agent also didn’t work. After looking through dozens of issues, tutorials, questions and stackoverflow, I found something that helped me.

In both servers, I set the socket timeout to 10 * 60 * 1000 (10 minutes) and wrapped the send email handler on «B» inside a 5 minutes timeout. You can choose smaller much values such as 10 and 20 secs, as long as socketTimeout(server) > setTimeout(handler) , but you’d also have to consider the time it’d take to execute the handler.

Then, I sent a request from «A» to «B»:

Источник

Error: socket hang up OR Error: connect ECONNREFUSED 127.0.0.1:42395 — when ‘docker’ and ‘devtools’ services are used together. #78

Comments

Pratikhanagodimath commented Mar 17, 2020

I am attempting to use docker and devtools service together to evaluate performance of a page. Running locally. I am running into issues when I include ‘devtools’ as a service along with docker service, without ‘devtools’ the test just runs fine. Below is the error I see. What am I missing?. Seems like same issue mentioned here by prathameshnyt -> #3744 (comment)

Error without the mention of chrome debuggerAddress

2020-03-16T22:29:25.397Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «docker»
2020-03-16T22:29:25.405Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «devtools»
2020-03-16T22:29:25.702Z INFO @wdio/cli:launcher: Run onPrepare hook
2020-03-16T22:29:25.703Z DEBUG wdio-docker-service: Docker command: docker run —cidfile /Users/phanagodimath/Desktop/Projects/Martech-Performance/selenium_standalone_chrome.cid —rm -p 4444:4444 —shm-size 2g selenium/standalone-chrome
2020-03-16T22:29:25.710Z WARN wdio-docker-service: Connecting dockerEventsListener: 6138
2020-03-16T22:29:25.712Z INFO wdio-docker-service: Shutting down running container
2020-03-16T22:29:26.074Z INFO wdio-docker-service: Cleaning up CID files
2020-03-16T22:29:26.127Z INFO wdio-docker-service: Launching docker image ‘selenium/standalone-chrome’
2020-03-16T22:29:26.471Z INFO wdio-docker-service: Container started: <
«args»: «»,
«image»: «selenium/standalone-chrome»,
«timeStamp»: «2020-03-16T22:29:26.480Z»,
«type»: «container.start»,
«status»: «start»,
«detail»: <
«id»: «3c9d234b53b5e9ff0997826cff84b8dd5b378595ea1da0363f205f56dbc94a0d»,
«scope»: «local»,
«actor»: <
«ID»: «3c9d234b53b5e9ff0997826cff84b8dd5b378595ea1da0363f205f56dbc94a0d»,
«Attributes»: <
«authors»: «SeleniumHQ»,
«image»: «selenium/standalone-chrome»,
«name»: «musing_elbakyan»
>
>
>
>
2020-03-16T22:29:26.587Z DEBUG wdio-docker-service: 2020-03-16 22:29:26,597 INFO Included extra file «/etc/supervisor/conf.d/selenium.conf» during parsing

2020-03-16T22:29:26.588Z DEBUG wdio-docker-service: 2020-03-16 22:29:26,598 INFO supervisord started with pid 7

2020-03-16T22:29:27.592Z DEBUG wdio-docker-service: 2020-03-16 22:29:27,603 INFO spawned: ‘xvfb’ with pid 10

2020-03-16T22:29:27.594Z DEBUG wdio-docker-service: 2020-03-16 22:29:27,605 INFO spawned: ‘selenium-standalone’ with pid 11

2020-03-16T22:29:28.066Z DEBUG wdio-docker-service: 22:29:28.075 INFO [GridLauncherV3.parse] — Selenium server version: 3.141.59, revision: e82be7d358
2020-03-16 22:29:28,078 INFO success: xvfb entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2020-03-16 22:29:28,078 INFO success: selenium-standalone entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)

2020-03-16T22:29:28.222Z DEBUG wdio-docker-service: 22:29:28.234 INFO [GridLauncherV3.lambda$buildLaunchers$3] — Launching a standalone Selenium Server on port 4444

2020-03-16T22:29:28.322Z DEBUG wdio-docker-service: 2020-03-16 22:29:28.327:INFO::main: Logging initialized @710ms to org.seleniumhq.jetty9.util.log.StdErrLog

2020-03-16T22:29:28.735Z DEBUG wdio-docker-service: 22:29:28.745 INFO [WebDriverServlet.] — Initialising WebDriverServlet

2020-03-16T22:29:28.896Z DEBUG wdio-docker-service: 22:29:28.908 INFO [SeleniumServer.boot] — Selenium Server is up and running on port 4444

2020-03-16T22:29:29.249Z INFO wdio-docker-service: Docker container is ready
2020-03-16T22:29:29.251Z INFO @wdio/local-runner: Start worker 0-0 with arg: config/wdio.conf.docker.js
[0-0] 2020-03-16T22:29:29.475Z INFO @wdio/local-runner: Run worker command: run
[0-0] RUNNING in chrome — /test/specs/basic_docker.js
[0-0] 2020-03-16T22:29:29.553Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «docker»
[0-0] 2020-03-16T22:29:29.558Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «devtools»
[0-0] 2020-03-16T22:29:29.840Z DEBUG @wdio/local-runner:utils: init remote session
[0-0] 2020-03-16T22:29:29.841Z INFO webdriverio: Initiate new session using the webdriver protocol
[0-0] 2020-03-16T22:29:29.843Z INFO webdriver: [POST] http://127.0.0.1:4444/wd/hub/session
[0-0] 2020-03-16T22:29:29.843Z INFO webdriver: DATA <
capabilities: < alwaysMatch: < browserName: ‘chrome’ >, firstMatch: [ <> ] >,
desiredCapabilities: < browserName: ‘chrome’ >
>
2020-03-16T22:29:29.989Z DEBUG wdio-docker-service: 22:29:30.002 INFO [ActiveSessionFactory.apply] — Capabilities are: <
«browserName»: «chrome»
>

2020-03-16T22:29:29.992Z DEBUG wdio-docker-service: 22:29:30.005 INFO [ActiveSessionFactory.lambda$apply$11] — Matched factory org.openqa.selenium.grid.session.remote.ServicedSession$Factory (provider: org.openqa.selenium.chrome.ChromeDriverService)

2020-03-16T22:29:30.032Z DEBUG wdio-docker-service: Starting ChromeDriver 80.0.3987.106 (f68069574609230cf9b635cd784cfb1bf81bb53a-refs/branch-heads/3987@<#882>) on port 7411

2020-03-16T22:29:30.037Z DEBUG wdio-docker-service: Only lo[c1a5l8 4c3o9n7n7e7c0t.i0o4n5s] [aSrEeV EaRlEl]o:w ebdi.n
Pdl(e)a sfea iplreodt:e cCta npnoortts used by C harsosmiegDnr irveerq uaensdt erde laadtderde stse s(t9 9f)r

2020-03-16T22:29:30.038Z DEBUG wdio-docker-service: ameworks to prevent access by malicious code.

2020-03-16T22:29:30.855Z DEBUG wdio-docker-service: 22:29:30.870 INFO [ProtocolHandshake.createSession] — Detected dialect: W3C

2020-03-16T22:29:30.919Z DEBUG wdio-docker-service: 22:29:30.934 INFO [RemoteSession$Factory.lambda$performHandshake$0] — Started new session 29c930f81189207ce9af3ddeadcf1107 (org.openqa.selenium.chrome.ChromeDriverService)

[0-0] (node:6155) UnhandledPromiseRejectionWarning: Error: connect ECONNREFUSED 127.0.0.1:34783
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1126:14)
[0-0] (node:6155) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:6155) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
^Z
[5]+ Stopped npm run test:docker

Error running with chrome debuggerAddress

2020-03-16T22:05:09.898Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «docker»
2020-03-16T22:05:09.903Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «devtools»
2020-03-16T22:05:10.176Z INFO @wdio/cli:launcher: Run onPrepare hook
2020-03-16T22:05:10.177Z DEBUG wdio-docker-service: Docker command: docker run —cidfile /Users/phanagodimath/Desktop/Projects/Martech-Performance/selenium_standalone_chrome.cid —rm -p 4444:4444 -p 9222:9222 —shm-size 2g —hostname selenium selenium/standalone-chrome
2020-03-16T22:05:10.182Z WARN wdio-docker-service: Connecting dockerEventsListener: 5857
2020-03-16T22:05:10.185Z INFO wdio-docker-service: Shutting down running container
2020-03-16T22:05:10.529Z INFO wdio-docker-service: Cleaning up CID files
2020-03-16T22:05:10.581Z INFO wdio-docker-service: Launching docker image ‘selenium/standalone-chrome’
2020-03-16T22:05:10.979Z INFO wdio-docker-service: Container started: <
«args»: «»,
«image»: «selenium/standalone-chrome»,
«timeStamp»: «2020-03-16T22:05:11.004Z»,
«type»: «container.start»,
«status»: «start»,
«detail»: <
«id»: «ec657e32cce91f66e021b65a52364b800b5ff2fbccbaad281b97cf9be7924ca3»,
«scope»: «local»,
«actor»: <
«ID»: «ec657e32cce91f66e021b65a52364b800b5ff2fbccbaad281b97cf9be7924ca3»,
«Attributes»: <
«authors»: «SeleniumHQ»,
«image»: «selenium/standalone-chrome»,
«name»: «focused_dirac»
>
>
>
>
2020-03-16T22:05:11.084Z DEBUG wdio-docker-service: 2020-03-16 22:05:11,109 INFO Included extra file «/etc/supervisor/conf.d/selenium.conf» during parsing

2020-03-16T22:05:11.085Z DEBUG wdio-docker-service: 2020-03-16 22:05:11,110 INFO supervisord started with pid 7

2020-03-16T22:05:12.095Z DEBUG wdio-docker-service: 2020-03-16 22:05:12,118 INFO spawned: ‘xvfb’ with pid 10
2020-03-16 22:05:12,120 INFO spawned: ‘selenium-standalone’ with pid 11

2020-03-16T22:05:12.548Z DEBUG wdio-docker-service: 22:05:12.572 INFO [GridLauncherV3.parse] — Selenium server version: 3.141.59, revision: e82be7d358

2020-03-16T22:05:12.548Z DEBUG wdio-docker-service: 2020-03-16 22:05:12,575 INFO success: xvfb entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2020-03-16 22:05:12,575 INFO success: selenium-standalone entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)

2020-03-16T22:05:12.703Z DEBUG wdio-docker-service: 22:05:12.730 INFO [GridLauncherV3.lambda$buildLaunchers$3] — Launching a standalone Selenium Server on port 4444

2020-03-16T22:05:12.805Z DEBUG wdio-docker-service: 2020-03-16 22:05:12.826:INFO::main: Logging initialized @694ms to org.seleniumhq.jetty9.util.log.StdErrLog

2020-03-16T22:05:13.207Z DEBUG wdio-docker-service: 22:05:13.232 INFO [WebDriverServlet.] — Initialising WebDriverServlet

2020-03-16T22:05:13.362Z DEBUG wdio-docker-service: 22:05:13.389 INFO [SeleniumServer.boot] — Selenium Server is up and running on port 4444

2020-03-16T22:05:13.706Z INFO wdio-docker-service: Docker container is ready
2020-03-16T22:05:13.708Z INFO @wdio/local-runner: Start worker 0-0 with arg: config/wdio.conf.docker.js
[0-0] 2020-03-16T22:05:13.937Z INFO @wdio/local-runner: Run worker command: run
[0-0] RUNNING in chrome — /test/specs/basic_docker.js
[0-0] 2020-03-16T22:05:14.024Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «docker»
[0-0] 2020-03-16T22:05:14.030Z DEBUG @wdio/utils:initialiseServices: initialise wdio service «devtools»
[0-0] 2020-03-16T22:05:14.312Z DEBUG @wdio/local-runner:utils: init remote session
[0-0] 2020-03-16T22:05:14.313Z INFO webdriverio: Initiate new session using the webdriver protocol
[0-0] 2020-03-16T22:05:14.315Z INFO webdriver: [POST] http://127.0.0.1:4444/wd/hub/session
[0-0] 2020-03-16T22:05:14.315Z INFO webdriver: DATA <
capabilities: < alwaysMatch: < browserName: ‘chrome’ >, firstMatch: [ <> ] >,
desiredCapabilities: < browserName: ‘chrome’ >
>
2020-03-16T22:05:14.461Z DEBUG wdio-docker-service: 22:05:14.490 INFO [ActiveSessionFactory.apply] — Capabilities are: <
«browserName»: «chrome»
>

2020-03-16T22:05:14.464Z DEBUG wdio-docker-service: 22:05:14.493 INFO [ActiveSessionFactory.lambda$apply$11] — Matched factory org.openqa.selenium.grid.session.remote.ServicedSession$Factory (provider: org.openqa.selenium.chrome.ChromeDriverService)

2020-03-16T22:05:14.508Z DEBUG wdio-docker-service: Starting Chro[m1e5D8r4i3v9e6r3 1840.529].[0S.E3V9E8R7E.]1:0 6b i(nfd6(8)0 6f9a5i7l4e6d0:9 2C3a0ncnfo9tb 6a3s5scidg7n8 4rcefqbu1e
2020-03-16T22:05:14.509Z DEBUG wdio-docker-service: bf81bb53a-refs/branch-heads/3987@<#882>) on port 31965

2020-03-16T22:05:14.509Z DEBUG wdio-docker-service: Only local connections are allowed.
Please protect ports used by ChrosmeDtreidv eard darneds sr e(l9a9t)e

2020-03-16T22:05:14.510Z DEBUG wdio-docker-service: d test frameworks to prevent access by malicious code.

2020-03-16T22:05:15.313Z DEBUG wdio-docker-service: 22:05:15.342 INFO [ProtocolHandshake.createSession] — Detected dialect: W3C

2020-03-16T22:05:15.374Z DEBUG wdio-docker-service: 22:05:15.403 INFO [RemoteSession$Factory.lambda$performHandshake$0] — Started new session 0488ca55b2f225efc8fbb340896f129b (org.openqa.selenium.chrome.ChromeDriverService)

[0-0] (node:5874) UnhandledPromiseRejectionWarning: Error: socket hang up
at connResetException (internal/errors.js:561:14)
at Socket.socketOnEnd (_http_client.js:440:23)
at Socket.emit (events.js:214:15)
at Socket.EventEmitter.emit (domain.js:476:20)
at endReadableNT (_stream_readable.js:1178:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
[0-0] (node:5874) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:5874) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
^Z
[4]+ Stopped npm run test:docker

Config of WebdriverIO

package.json file

Test

Steps to reproduce the behavior

In wdio config, use services: [‘docker’, [‘devtools’, < debuggerAddress: ‘localhost:9222’ >]] and run any simple test.

Expected behavior
Test should run in the docker container along with devtools service which will provide performance metrics.

The text was updated successfully, but these errors were encountered:

Источник