ETIMEDOUT during syscall connect()

[roderickObrist]

Hi All,

• v8.9.1:
• Linux Rod-Desktop 4.13.0-17-generic Confirmation around contributing #20-Ubuntu SMP Mon Nov 6 10:04:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux:

I'm running a bot that does mostly https requests, sitting only on around 5 https requests per second MAX. My bot scrapes 5 different reliable websites.

I've found that every 100 or so https requests I get"

{ Error: connect ETIMEDOUT 216.58.200.106:443
    at Object._errnoException (util.js:1024:11)
    at _exceptionWithHostPort (util.js:1046:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1182:14)
  code: 'ETIMEDOUT',
  errno: 'ETIMEDOUT',
  syscall: 'connect',
  address: '216.58.200.106',
  port: 443 }

Some deeper searching into the stacks and things tell me that its the underlying TCPWrap . syscall connect() is returning a -110 status error (which means timeout).
To my understanding the tcp socket is not making it to the remote server, the timeout happens when Linux cannot allocate a tcp socket to nodejs.

I've also seen this v8 error as well, which I don't think I would see unless it was a node bug.

/usr/bin/node[5665]: ../src/util-inl.h:243:TypeName* node::Unwrap(v8::Local<v8::Object>) [with TypeName = node::TLSWrap]: Assertion `(object->InternalFieldCount()) > (0)' failed.
 1: node::Abort() [/usr/bin/node]
 2: node::Assert(char const* const (*) [4]) [/usr/bin/node]
 3: void node::StreamBase::GetBytesRead<node::TLSWrap>(v8::Local<v8::String>, v8::PropertyCallbackInfo<v8::Value> const&) [/usr/bin/node]
 4: v8::internal::PropertyCallbackArguments::Call(void (*)(v8::Local<v8::Name>, v8::PropertyCallbackInfo<v8::Value> const&), v8::internal::Handle<v8::internal::Name>) [/usr/bin/node]
 5: v8::internal::Object::GetPropertyWithAccessor(v8::internal::LookupIterator*) [/usr/bin/node]
 6: v8::internal::Object::GetProperty(v8::internal::LookupIterator*) [/usr/bin/node]
 7: v8::internal::JSReceiver::GetOwnPropertyDescriptor(v8::internal::LookupIterator*, v8::internal::PropertyDescriptor*) [/usr/bin/node]
 8: v8::internal::JSReceiver::GetOwnPropertyDescriptor(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDescriptor*) [/usr/bin/node]
 9: v8::internal::Builtin_ObjectGetOwnPropertyDescriptor(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/bin/node]
10: 0x16a16ca8441d

To be clear, I'm quite certain it's not a poor internet connection because it happens on different web endpoints randomly, also I have a fibre connection (as good as it gets in Australia).

I've been running this exact program for months now, but this only started happening when I installed Ubuntu 17.10, but I keep my node versions up to date too, perhaps this was included in a newer release.

I've also attached a chrome devtools stack trace, if that helps

[bnoordhuis]

ETIMEDOUT errors are a fact of life, you just need to handle them like you would any other run-time error. They mean the TCP handshake didn't complete within a sufficient time frame.

Do you get that assertion error while debugging with the inspector? That should be fixed in the next release.

[roderickObrist]

I have no issue with network timeout errors, I know how to handle them and have been handling them for 5 years.

But I don't think that's what this is, because it's not a network or remote server issue. It's a localised issue that only happens on this server. This is a timeout between nodejs and the linux syscall connect(), not between my local server and a remote server on the network layer.

I've been running this software for 4 months, as soon as I switched to Ubunutu 17.10 I started getting these issues.

And yes, I did get that v8 trace while running inspector, it's great to see you guys are on top of it :).

[bnoordhuis]

Ah, okay. You're probably hitting a kernel bug. I can confirm from first-hand experience that the 4.13.0-x kernel in 17.10 has some teething issues.

Nothing node.js can do about that; try reporting it to Ubuntu. I'll close this out but thanks for the report.