Error socket hang up перевод

Я пытаюсь сделать запрос GET на какой-то сайт (не мой собственный сайт) через http-модуль узла.Яш версию 0.8.14. Вот мой код (CoffeeScript):

Я пытаюсь сделать запрос GET на какой-то сайт (не мой собственный сайт) через http-модуль узла.Яш версию 0.8.14. Вот мой код (CoffeeScript):

options = 
        host: 'www.ya.ru'
        method: 'GET'
    req = http.request options, (res) ->
        output = ''
        console.log 'STATUS: ' + res.statusCode
        res.on 'data', (chunk) ->
            console.log 'A new chunk: ', chunk
            output += chunk

        res.on 'end', () ->
            console.log output
            console.log 'End GET Request'

    req.on 'error', (err) ->
        console.log 'Error: ', err
    req.end()

во время этой операции я получаю следующую ошибку: { [Ошибка: socket hang up] код: ‘ECONNRESET’ }. Если я прокомментирую обработчик ошибок, мое приложение завершится со следующей ошибкой:

events.js:48
    throw arguments[1]; // Unhandled 'error' event
    ^
Error: socket hang up
    at createHangUpError (http.js:1091:15)
    at Socket.onend (http.js:1154:27)
    at TCP.onread (net.js:363:26)

Я пытаюсь найти решение в интернете, но до сих пор не нашли их. Как решить эту проблему?

7 ответов

вы должны завершить запрос. Добавьте это в конце вашего скрипта:

req.end()

при использовании http.request(), вы должны в какой-то момент вызов request.end().

req = http.request options, (res) ->
    # ...

req.on 'error', # ...

req.end() # <---

до request остается открытым, чтобы разрешить написании тело. И ошибка заключается в том, что сервер в конечном итоге сочтет соединение истекшим и закроет его.

кроме того, вы также можете использовать http.get() С GET запросы, которые будем называть .end() автоматически начиная с GET запросы обычно не ожидается, что тело.

15

автор: Jonathan Lonowski

в моем случае это был ‘Content-Length’ заголовок-я вытащил его, и теперь все в порядке…

код:

function sendRequest(data)
{
    var options = {
              hostname: host,
              path: reqPath,
              port: port,
              method: method,
              headers: {
                      'Content-Length': '100'
              }
    var req = http.request(options, callback);
    req.end();
    };

после удаления строки: ‘Content-Length’:’100′ он разобрался.

Я, наконец, обнаружил проблему и нашли решение. Проблема в том, что я использую прокси-сервер для подключения к интернету. Вот рабочий код:

options = 
    hostname: 'myproxy.ru'
    path: 'http://www.ya.ru'
    port: 3128
    headers: {
        Host: "www.ya.ru"
    }
req = http.request options, (res) ->
    output = ''
    console.log 'STATUS: ' + res.statusCode
    res.on 'data', (chunk) ->
        console.log 'A new chunk: ', chunk
        output += chunk

    res.on 'end', () ->
        console.log output
        console.log 'End GET Request'

req.on 'error', (err) ->
    console.log 'Error: ', err
req.end()

спасибо всем за помощь и предложения!

Я обнаружил, что это происходит в одном случае, когда я отправлял пустое тело, как — ‘{}’ в операции delete вызывается из интерн фреймворк для тестирования;
вместо этого я использовал null для отправки в качестве значения параметра body при выполнении запроса через

при обновлении с 0.10.33 до 0.12 nodejs эта ошибка была нажата.

в моем случае для запроса на удаление было тело (json). Ранее клиент узла устанавливал-‘ transfer — encoding ‘как chunked-по умолчанию, когда» content-length » не установлен. Кажется, в последней версии клиент узла перестал устанавливать передачу-кодирование по умолчанию.

Fix должен был установить его в запросе.

в моем случае, после обновления до node 8.0.0 пост не работает. добавление Content-Length заголовок не помогает. Нужно добавить 'Connection': 'keep-alive' до заголовок чтобы получить эту ошибку подальше. 

    let postOptions = {
        method: 'POST',
        form: form,
        url: finalUrl,
        followRedirect: false,
        headers:{
            'Connection': 'keep-alive'
        }
    };
    request(postOptions, handleSAMLResponse);
Источник

Есть два случая, когда socket hang up бросается:

Когда вы клиент

Когда вы, как клиент, отправляете запрос на удаленный сервер и не получаете своевременного ответа. Ваш сокет завершен, что вызывает эту ошибку. Вы должны поймать эту ошибку и решить, как с ней справиться: повторить ли запрос, поставить его в очередь на потом и т. д.

Когда вы сервер/прокси

Когда вы, как сервер, возможно, прокси-сервер, получаете запрос от клиента, затем начинаете действовать по нему (или ретранслируете запрос вышестоящему серверу), и до того, как вы подготовили ответ, клиент решает отменить/прервать запрос.

Эта трассировка стека показывает, что происходит, когда клиент отменяет запрос.

Trace: { [Error: socket hang up] code: 'ECONNRESET' }
    at ClientRequest.proxyError (your_server_code_error_handler.js:137:15)
    at ClientRequest.emit (events.js:117:20)
    at Socket.socketCloseListener (http.js:1526:9)
    at Socket.emit (events.js:95:17)
    at TCP.close (net.js:465:12)

линия http.js:1526:9указывает на то же самое socketCloseListener упоминается @Blender, в частности:

// This socket error fired before we started to
// receive a response. The error needs to
// fire on the request.
req.emit('error', createHangUpError());

...

function createHangUpError() {
  var error = new Error('socket hang up');
  error.code = 'ECONNRESET';
  return error;
}

Это типичный случай, если клиент является пользователем в браузере. Запрос на загрузку какого-либо ресурса/страницы занимает много времени, и пользователи просто обновляют страницу. Такое действие приводит к прерыванию предыдущего запроса, что на стороне вашего сервера вызывает эту ошибку.

Поскольку эта ошибка вызвана желанием клиента, он не ожидает получить какое-либо сообщение об ошибке. Так что не стоит считать эту ошибку критической. Просто игнорируйте это. Этому способствует тот факт, что при такой ошибке res сокет, который слушал ваш клиент, хотя и доступен для записи, но уничтожен.

console.log(res.socket.destroyed); //true

Итак, нет смысла отправлять что-либо, кроме явного закрытия объекта ответа:

res.end();

Однако то, что вы следует сделать конечно, если вы Он прокси-сервер, который уже передал запрос восходящему потоку, должен прервать ваш внутренний запрос к восходящему, указывая на ваше отсутствие интереса к ответу, что, в свою очередь, скажет вышестоящему серверу, возможно, остановить дорогостоящую операцию.

Источник

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
Источник

Содержание

  1. [ConfigProxy] Proxy error: Error: socket hang up #1244
  2. Comments
  3. Newman behind corporate proxy fails with «socket hang up» #818
  4. Comments
  5. [UIAutomator2] Could not proxy command to remote server. Original error: Error: socket hang up #8159
  6. Comments
  7. The problem
  8. Environment
  9. Details
  10. Link to Appium logs
  11. Code To Reproduce Issue [ Good To Have ]

[ConfigProxy] Proxy error: Error: socket hang up #1244

I have jupyterhub installation on a linux machine, installed in a dedicated conda environment without any custom configuration. I connect to this server from other computers in the same local network using linux user authentication and I was really pleased to see jupyterhub working out of the box when I installed the system 2-3 months ago.

Today however I started having some issues 🙂

After user login a server is started but the dashboard does not shows the files. After some seconds I get an error in the terminal I started jupyterhub from:

Nothing changed to the configuration, nor I update conda packages.

Any help is appreciated.

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

I want to add that the issue is transient, so it doesn’t happens all the times. I though about a network issue, but when it happens I can still ssh into the server without problems.

@yuvipanda, so far we have only one linux user, but with two people using it at the same time.

Socket hangups will occur if the upstream socket is closed while a request is outstanding, or if a server is slow to start and accepts connections, but isn’t actually ready to start replying to requests. A totally reasonable way to cause this is to shutdown a server while a browser is talking to it. It wasn’t really appropriate for the proxy to log tracebacks when this happens, as that suggests something is more wrong than it is.

Can you include more log context prior to the errors? Does this generally happen when a user’s server is just starting, or when another particular activity is going on at the same?

jupyterhub/configurable-http-proxy#118 replaces these tracebacks with lighter logs of the 503 errors.

Of course, now that I reported it it doesn’t happen anymore. Yesterday I had to restart jupyterhub several times before I could work.

I usually have long running sessions, I’m connecting to the sever via a laptop which goes to sleep/wakes up several times. Sometimes, the kernel gets unresponsive and I have to use the menu Kernel -> Reconnect. Other times I disconnect from the internal LAN and reconnect using SSH tunneling from another network to the same open session (i.e. notebook). When the error occurs, the notebook become unresponsive and I’m not able to reconnect to the server anymore. Trying to restart jupyterhub, I can log in but I cannot even reach the dashboard with the list of files.

I’ll keep monitoring the situation and report a longer log if it happens again.

I’m glad it’s working at the moment. Just for future troubleshooting/history, would you mind, if you have time, adding a note on which version of JupyterHub and the proxy that you are using as well as any particular authenticator/spawner details (if they are different from the default)?

Thanks! Let’s leave this open for a week. If we don’t see anything related in that timeframe, I will close this. We can always open a new issue and reference this one.

I use jupyterhub 0.7.2. The complete conda environment is:

No custom configuration, it literally started working out of the box after typing jupyterhub 👏

The error happened again. Now trying to open a notebook or a terminal fails and this appears in the terminal:

Unfortunately I cannot get a longer log because I’m copying-pasting using screen. I’ll log the session next time.

Thanks for sharing the info @tritemio.

If it can help, I noticed that the server had some heavy delay in reading from disk during the time I got the issue. A simple ls took several seconds before showing the output. It is strange given that there was no load at all.

@willingc, is not closing it now a little premature? I understand the need to prune issues, but I posted new logs 2 days ago and the issue is only 3 days old.

EDIT: sorry I didn’t noticed the PR, please discard my comment.

@tritemio No worries. Looks like Min’s PR on CHP autoclosed this one. I’m happy to reopen this if you find that the PR does not resolve your issue. Just let us know. Thanks 👍

@willingc, if I understand correctly the PR jupyterhub/configurable-http-proxy#118 changed only the error messages.

I’m still getting the issue of notebook-app not responding. This time I was closing a bunch of notebooks and jupyter terminals. While doing so, the server become unresponsive and this is the log:

I have been starting to get a similar error with intermittent connectivity, I am not sure where it is stemming from. Our IT just migrated our domain to a cloud base domain and it started happening, it would seem that it could be related but I can’t seem to find a solution. Any ideas on how I could troubleshoot this? @minrk @willingc
@tritemio Did you ever resolve your issue?

14:31:28.493 — error: [ConfigProxy] Proxy error: Error: socket hang up at createHangUpError (_http_client.js:330:15) at Socket.socketCloseListener (_http_client.js:362:23) at Socket.emit (events.js:165:20) at TCP._handle.close [as _onclose] (net.js:559:12) 14:31:28.494 — error: [ConfigProxy] 503 GET /hub/user/youri.nelson/ [I 2018-04-03 14:31:28.517 JupyterHub log:122] 200 GET /hub/error/503?url=%2Fhub%2Fuser%2Fyouri.nelson%2F (@127.0.0.1) 20.66ms [I 2018-04-03 14:31:28.517 JupyterHub log:122] 200 GET /hub/error/503?url=%2Fhub%2Fuser%2Fyouri.nelson%2F (@127.0.0.1) 20.66ms

The issue I reported was probably due to a link to a remote shared folder (via samba) in the user’s home directory. The shared folder is on a windows computer and sometimes the samba connection gets stuck. After I unmount an remount the folder, the jupyter notebook starts again to be responsive.

To check if this is the issue, I connect via ssh and do ls on the user’s home. If the commands gets stuck, there is a problem with the shared folder and also the jupyter notebook will have issues. Remounting the folder umount -lf folder && mount folder fixes the issue.

@tritemio I do have a shared folder used for jupyterhub that my team connects to via samba but when I go to the folder on the server there is no hang up. I’ll try restarting samba to see if that helps at all.

I came across this issue because I’m facing a similar problem. My Mac freezes when I run Jupyterhub locally and try to log in. I can’t even provide a traceback because the mouse turns to a spinning wheel and stops responding, forcing me to manually power cycle my computer. Not sure how I can debug this.

It turns out if I wait close to 5 minutes it launches: «User nscozzar took 284.206 seconds to start»
I think I must have the same samba issue as @tritemio.

Closing as this sounds like a OS problem. If you need more help please post on the Discourse forum.

Источник

Newman behind corporate proxy fails with «socket hang up» #818

  1. Newman Version (can be found via newman -v ): 3.3.0
  2. OS details (type, version, and architecture): Windows7 Enterprise, 64 Bit Intel Core i7
  3. Are you using Newman as a library, or via the CLI? CLI (through Jenkins and direct bash script)
  4. Did you encounter this recently, or has this bug always been there: Only using newman since 3.3.0
  5. Expected behaviour: Consistent results for the testing done to the collection, with no random failures due to proxy
  6. Command / script used to run Newman: newman run Collection.json -e env.json -k —disable-unicode -r junit,cli
  7. Sample collection, and auxilliary files (minus the sensitive details):
    I made a test collection pointing to Httpbin.org

<
«variables»: [],
«info»: <
«name»: «HTTPBin»,
«_postman_id»: «ba9d25c1-bcd2-4a7e-cd8c-baa37b4af407»,
«description»: «Base API testing collection to serve as a positive control for Jenkinsn»,
«schema»: «https://schema.getpostman.com/json/collection/v2.0.0/collection.json»
>,
«item»: [
<
«name»: «get»,
«event»: [
<
«listen»: «test»,
«script»: <
«type»: «text/javascript»,
«exec»: [
«tests[«Status code is 200″] = responseCode.code === 200;»,
«»,
«var jsonData = JSON.parse(responseBody);»,
«tests[«Host correct»] = jsonData.headers.Host == «httpbin.org»;»
]
>
>
],
«request»: <
«url»: «https://httpbin.org/get»,
«method»: «GET»,
«header»: [],
«body»: <>,
«description»: «»
>,
«response»: []
>
]
>

and the env.json file:
<
«id»: «35c0b2b8-6506-e43b-f39f-242923416836»,
«name»: «HTTPBin»,
«values»: [
<
«key»: «HTTPS_PROXY»,
«type»: «text»,
«value»: «http://proxyURL:8080»,
«enabled»: true
>,
<
«key»: «HTTP_PROXY»,
«type»: «text»,
«value»: «http://proxyURL:8080»,
«enabled»: true
>
],
«timestamp»: 1481796886584,
«_postman_variable_scope»: «environment»,
«_postman_exported_at»: «2016-12-15T10:14:49.984Z»,
«_postman_exported_using»: «Postman/4.9.2»
>
The test.sh script called from Jenkins is:
#!/usr/bin/bash
/path/to/newman run Collection.json -e env.json -k —disable-unicode -r junit,cli
7. Screenshots (if applicable):
Fail in Jenkins

Success in Jenkins

Fail in CLI

Success in CLI

Steps to reproduce the problem:

  1. Execute the script in the same folder the env.json and Collection.json files
  2. Repeat 10-15 times every 2-5 miuntes
  3. Alternatively, set up a Jenkins job and analyze the failure pattern

The only sensitive information is the corporate proxy setup. In the internet settings panel, is set up with a setup script:

I located a normal proxy inside the file and use it as the proxy in Postman and set it up with HTTP_PROXY/HTTPS_PROXY environment variables for the newman run.

The ideal solution would be for Postman/newman to be able to digest proxy configuration scripts directly through the url, but handling the proxy correctly by direct input would be enough for me.

Thanks in advance and if you need any additional information, i’d be glad to help.

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

Источник

[UIAutomator2] Could not proxy command to remote server. Original error: Error: socket hang up #8159

The problem

During ARC command execution, suddenly commands stops working with error

Selenium::WebDriver::Error::UnknownError: An unknown server-side error occurred while processing the command. Original error: Could not proxy command to remote server. Original error: Error: socket hang up

Environment

  • Appium version (or git revision) that exhibits the issue: 1.6.4-beta
  • Last Appium version that did not exhibit the issue (if applicable): NA
  • Desktop OS/version used to run Appium: Mac 10.11.6
  • Node.js version (unless using Appium.app|exe): v7.6.0
  • Mobile platform/version under test: Nexus 5, 6.0.1
  • Real device or emulator/simulator: Real Device
  • Appium CLI or Appium.app|exe: CLI

Details

Using ARC to probe the app and look into locators. While doing this it’s observed that commands stops working with error

Selenium::WebDriver::Error::UnknownError: An unknown server-side error occurred while processing the command. Original error: Could not proxy command to remote server. Original error: Error: socket hang up

Link to Appium logs

Code To Reproduce Issue [ Good To Have ]

Please remember that with sample code it’s easier to reproduce the bug and it’s much faster to fix it.

Please git clone https://github.com/appium/sample-code and use one of your favourite languages and sample apps to reproduce the issue.

In case a similar scenario is missing in sample-code, please submit a PR with one of the sample apps provided.

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

After this I stopped appium server and arc as well. Restarted both and getting new kind of errors

When I rund adb devices, it does show device name under list of devices

I had to restart device -> appium server -> arc to get whole setup up and running again.

Please let me know if you need more info / logs on this issue

Duplicate of #8100
It looks like something is broken in Android SDK — probably updating it will help

@mykola-mokhnach can you please clarify how is this related to SDK older version ? I’m trying to run automation on real device and not on emulator.

Real device is running Android OS 6.0.1

@vikramvi, Can you share adb logs for the same? (please do clear existing logs before execution using adb logcat -c command )

I am seeing this intermittently with android devices on Appium 1.6.5 desktop (with updates) and using the ruby Appium_lib gem 9.4.7. I am not having any particular issues with adb , although I’ve noticed that when Appium is running it seems to be able to make adb unreliable. I’ve updated everything in Android Studio. The same suite run on the same hardware produces different results each time 🙁

i met this error too.
appium version 1.7.1
mac os 10.12

  • I used desired_caps[‘automationName’] = ‘Uiautomator2’ in a python scritp to catch toast message, while got a error msg that appium-uiautomator2-server-v0.1.8.apk doesn’t exist;
  • Then I used npm -g install appium-uiautomator2-driver@0.1.8 to install , however, it failed, there were not 0.1.8 vesion availabe;
  • Next I used npm -g install appium-uiautomator2-driver, it successd, the version is v-0.2.1
  • Next I re-run the script, still met a error msg cannot find appium-uiautomator2-server-v0.1.8.apk
  • Then I copy appium-uiautomator2-server-v0.1.8.apk from appium-desktop(path:/Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-uiautomator2-driver/uiautomator2/appium-uiautomator2-server-v0.1.8.apk to /usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-driver/uiautomator2
  • Next I run my python scription(with out desired_caps[‘automationName’] = ‘Uiautomator2’, the scription runs normally), I met the fellowing errors at last.

[debug] [ADB] Running ‘/Users//Library/Android/sdk/platform-tools/adb’ with args: [«-P»,5037,»-s»,»emulator-5554″,»shell»,»ime»,»set»,»io.appium.android.ime/.UnicodeIME»]
[debug] [ADB] Getting connected devices.
[debug] [ADB] 1 device(s) connected
[debug] [ADB] Running ‘/Users//Library/Android/sdk/platform-tools/adb’ with args: [«-P»,5037,»-s»,»emulator-5554″,»shell»,»am»,»force-stop»,»io.hx58wallet»]
[debug] [Logcat] Stopping logcat capture
[debug] [ADB] Removing forwarded port socket connection: 8200
[debug] [ADB] Running ‘/Users/*******/Library/Android/sdk/platform-tools/adb’ with args: [«-P»,5037,»-s»,»emulator-5554″,»forward»,»—remove»,»tcp:8200″]
[MJSONWP] Encountered internal error running command: ProxyRequestError: Could not proxy command to remote server. Original error: Error: socket hang up
at JWProxy.proxy$ (../../../lib/jsonwp-proxy/proxy.js:152:13)
at tryCatch (/usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-driver/node_modules/_babel-runtime@5.8.24@babel-runtime/regenerator/runtime.js:67:40)
at GeneratorFunctionPrototype.invoke [as _invoke] (/usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-driver/node_modules/_babel-runtime@5.8.24@babel-runtime/regenerator/runtime.js:315:22)
at GeneratorFunctionPrototype.prototype.(anonymous function) [as throw] (/usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-driver/node_modules/_babel-runtime@5.8.24@babel-runtime/regenerator/runtime.js рџ’Ї 21)
at GeneratorFunctionPrototype.invoke (/usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-driver/node_modules/_babel-runtime@5.8.24@babel-runtime/regenerator/runtime.js:136:37)
at

An unknown server-side error occurred while processing the command. Original error: Could not proxy command to remote server. Original error: Error: read ECONNRESET (WARNING: The server did not provide any stacktrace information)

I’m getting this error a lot, frustrating just to get appium connected to the device sometimes. I think it may be a fault of node, or how it communicates to appium.

Timeouts at 60 seconds are also common

also met this problem a lot,but i still have no idea about it.

having same issue. any resolution or handling of this on Appium’s end??

Reproduced with Appium Server 1.8.1 on real device at SauceLabs cloud:

I am also facing the same issue, are there any fix for this ?

I am seeing the following error message

Socket hang up issue might pop up due to multiple reasons, which, usually, have nothing to do with Appium or UIA2 server component. For example: problems with device hardware, network issues, adb issues, etc. Getting adb logcat output and analysing it for possible stack traces/crashes might help to catch a problem in some cases though.

@manishthackray Since no one has ever produced the device logs (from adb logcat , as has been requested multiple times) there is nothing that can be helped here.

Источник

Источник

Понравилась статья? Поделить с друзьями:
  • Error socket does not name a type
  • Error soc init t17 antminer
  • Error soc init s19
  • Error soc init s17
  • Error snowshoe 593036c0