socket hang up when doing several http requests inside my flow - httprequest
I'm having an issue in Node-red when in my flow I have several http requests to another services in my node-red. As far as I can see the error always comes when I do the second call to the same domain (i.e.: localhost, although it could be with another domain)
As summary: I have 2 different flows:
One as a gitlab interface for retrieving files from there. So from here I call to the gitlab server (Flow 1)
Another one my application, that needs to retrieve 2 different files. From this flow, I call 2 times to the previous flow (Flow 2)
So, once my second flow is started, and after some JavaScript and switch nodes, I call by the first time to to first flow, which calls to gitlab. This works absolutely fine
The second flow continues and calls again, after another JavaScript nodes, to the first flow, and it seems that the flow is freezes and nothing happens, and after 2 minutes I get this error:
4 Apr 16:18:11 - [error] [http request:get_file] no response from server
4 Apr 16:18:11 - [error] [http request:get_file] Error: socket hang up
4 Apr 16:18:11 - [warn] [function:prepare_output] [navigations 3ef90eaf.c106f2] Error retrieving the data from the storage
Error: socket hang up : http://localhost:1880/gitlab_interface/file?...
4 Apr 16:18:11 - [warn] [function:init] [navigations 3ef90eaf.c106f2] Let's raise an error: ECONNRESET | Error retrieving the data from the storage
4 Apr 16:18:11 - [info] [function:init] [navigations 3ef90eaf.c106f2] Error raised: ECONNRESET | Error retrieving the data from the storage
Error: request aborted
at IncomingMessage.onAborted (...\node-red-0.16.2\node_modules\body-parser\node_modules\raw-body\index.js:269:10)
at emitNone (events.js:67:13)
at IncomingMessage.emit (events.js:166:7)
at abortIncoming (_http_server.js:280:11)
at Socket.serverSocketCloseListener (_http_server.js:293:5)
at emitOne (events.js:82:20)
at Socket.emit (events.js:169:7)
at TCP._onclose (net.js:477:12)
Do you have an idea what could be the error?
I've searched in internet about this error in nodejs, for instance:
Nodejs Socket hang up & ECONNRESET - HTTP post request from Meteor to Node js server
Node.js POST causes [Error: socket hang up] code: 'ECONNRESET'
Node js ECONNRESET
I've been testing locally some of these possible solutions (modifying the library follow-redirects and the node 21-httprequest.js) but without any success, so I'm lost about why this error occurs
I've tried also to set a delay, just to be sure that it's not a timing issue
I'm using node-red v0.16.2 and nodejs v4.4.3
Thanks in advance,
regards.
PS: I've done a test with metrics active:
λ node red.js
5 Apr 18:17:31 - [info]
Welcome to Node-RED
===================
5 Apr 18:17:31 - [info] Node-RED version: v0.16.2
5 Apr 18:17:31 - [info] Node.js version: v4.4.3
5 Apr 18:17:31 - [info] Windows_NT 6.1.7601 x64 LE
5 Apr 18:17:32 - [info] Loading palette nodes
5 Apr 18:17:34 - [warn] ------------------------------------------------------
5 Apr 18:17:34 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
5 Apr 18:17:34 - [warn] [tail] Not currently supported on Windows.
5 Apr 18:17:34 - [warn] ------------------------------------------------------
5 Apr 18:17:34 - [info] Settings file : C:\Users\myuser\.node-red\settings.js
5 Apr 18:17:34 - [info] User directory : C:\Users\myuser\.node-red
5 Apr 18:17:34 - [info] Flows file : C:\Users\myuser\.node-red\flows_LAPTOP.json
5 Apr 18:17:34 - [info] Server now running at http://127.0.0.1:1880/
5 Apr 18:17:34 - [debug] loaded flow revision: 2c8bff6298ad76b74c43e90797e50981
5 Apr 18:17:34 - [debug] red/runtime/nodes/credentials.load : no user key present
5 Apr 18:17:34 - [debug] red/runtime/nodes/credentials.load : using default key
5 Apr 18:17:34 - [info] Starting flows
5 Apr 18:17:34 - [info] Started flows
5 Apr 18:17:34 - [audit] {"event":"comms.open","level":98,"timestamp":1491409054876}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"eb5384b9.2266c8","event":"node.http in.send","msgid":"1a5f4041.e5a0c","timestamp":1491409060573}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"25a9b4b.377a64c","event":"node.function.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409060575}
5 Apr 18:17:40 - [info] [function:init] [flow2 1a5f4041.e5a0c] URL: '/mygroup/mysecondflow?query=string' | Headers JSON: '{"host":"localhost:1880","connection":"keep-alive","cache-control":"no-cache","user-agent":"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36","postman-token":"e84cf5b7-2d90-af9f-7367-93e758b5fbf1","accept":"*/*","accept-encoding":"gzip, deflate, sdch, br","accept-language":"en-US,en;q=0.8"}'
5 Apr 18:17:40 - [info] [function:init] [flow2 1a5f4041.e5a0c] Received token: undefined
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"25a9b4b.377a64c","event":"node.function.send","msgid":"1a5f4041.e5a0c","timestamp":1491409060585}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"a03d1790.77f638","event":"node.function.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409060586}
5 Apr 18:17:40 - [info] [function:validations] [flow2 1a5f4041.e5a0c] 'ok'
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"a03d1790.77f638","event":"node.function.send","msgid":"1a5f4041.e5a0c","timestamp":1491409060588}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"4911f030.be699","event":"node.switch.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409060589}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"4911f030.be699","event":"node.switch.send","msgid":"1a5f4041.e5a0c","timestamp":1491409060593}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"3d1c9dd1.ab5c02","event":"node.switch.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409060594}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"3d1c9dd1.ab5c02","event":"node.switch.send","msgid":"1a5f4041.e5a0c","timestamp":1491409060596}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"404be498.cbc77c","event":"node.http request.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409060597}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"a03d1790.77f638","event":"node.function.duration","msgid":"1a5f4041.e5a0c","value":40.66,"timestamp":1491409060628}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"25a9b4b.377a64c","event":"node.function.duration","msgid":"1a5f4041.e5a0c","value":52.38,"timestamp":1491409060629}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"fbe50847.a50258","event":"node.http in.send","msgid":"81687733.7e9788","timestamp":1491409060644}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"4aa21f88.5424d","event":"node.function.receive","msgid":"81687733.7e9788","timestamp":1491409060645}
5 Apr 18:17:40 - [info] [function:init] [flow1 81687733.7e9788] URL: '/gitlab_interface/file?query=string' | Headers JSON: '{"host":"localhost:1880","connection":"close"}'
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"4aa21f88.5424d","event":"node.function.send","msgid":"81687733.7e9788","timestamp":1491409060653}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"7fe7c062.5373b","event":"node.function.receive","msgid":"81687733.7e9788","timestamp":1491409060654}
5 Apr 18:17:40 - [info] [function:validations] [flow1 81687733.7e9788] Validations OK
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"7fe7c062.5373b","event":"node.function.send","msgid":"81687733.7e9788","timestamp":1491409060663}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"29d0fe16.a77122","event":"node.switch.receive","msgid":"81687733.7e9788","timestamp":1491409060663}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"29d0fe16.a77122","event":"node.switch.send","msgid":"81687733.7e9788","timestamp":1491409060664}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"266fb8b2.d3bc78","event":"node.function.receive","msgid":"81687733.7e9788","timestamp":1491409060665}
5 Apr 18:17:40 - [info] [function:prepare_request_2_gitlab] [flow1 81687733.7e9788] GitLab server retrieved: https://gitlab.myserver.com
5 Apr 18:17:40 - [info] [function:prepare_request_2_gitlab] [flow1 81687733.7e9788] URL for calling GitLab:
https://gitlab.myserver.com/api/v3/projects/123/repository/files?file_path=...
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"266fb8b2.d3bc78","event":"node.function.send","msgid":"81687733.7e9788","timestamp":1491409060668}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"30f49e7b.f00732","event":"node.http request.receive","msgid":"81687733.7e9788","timestamp":1491409060669}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"266fb8b2.d3bc78","event":"node.function.duration","msgid":"81687733.7e9788","value":34.25,"timestamp":1491409060700}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"7fe7c062.5373b","event":"node.function.duration","msgid":"81687733.7e9788","value":39.82,"timestamp":1491409060701}
5 Apr 18:17:40 - [metric] {"level":99,"nodeid":"4aa21f88.5424d","event":"node.function.duration","msgid":"81687733.7e9788","value":55.35,"timestamp":1491409060701}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"30f49e7b.f00732","event":"node.http request.duration.millis","msgid":"81687733.7e9788","value":"763.865","timestamp":1491409061433}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"30f49e7b.f00732","event":"node.http request.size.bytes","msgid":"81687733.7e9788","value":786,"timestamp":1491409061434}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"30f49e7b.f00732","event":"node.http request.send","msgid":"81687733.7e9788","timestamp":1491409061435}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"8cb13df8.2bdf8","event":"node.function.receive","msgid":"81687733.7e9788","timestamp":1491409061436}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"8cb13df8.2bdf8","event":"node.function.send","msgid":"81687733.7e9788","timestamp":1491409061436}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"982f8a3a.44e808","event":"node.function.receive","msgid":"81687733.7e9788","timestamp":1491409061437}
5 Apr 18:17:41 - [info] [function:Base64] ewogICJkYXRvMSI6ICJ2YWxvcjEiLAogICJkYXRvMiI6ICJ2YWxvcjIiICAKfQo=
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"982f8a3a.44e808","event":"node.function.send","msgid":"81687733.7e9788","timestamp":1491409061440}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"dda129a5.c079c8","event":"node.http response.receive","msgid":"81687733.7e9788","timestamp":1491409061441}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"fbe50847.a50258","event":"node.http in.response.time.millis","msgid":"81687733.7e9788","value":"803.156","timestamp":1491409061447}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"fbe50847.a50258","event":"node.http in.response.content-length.bytes","msgid":"81687733.7e9788","value":"60","timestamp":1491409061448}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"982f8a3a.44e808","event":"node.function.duration","msgid":"81687733.7e9788","value":13.29,"timestamp":1491409061451}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"8cb13df8.2bdf8","event":"node.function.duration","msgid":"81687733.7e9788","value":15.6,"timestamp":1491409061452}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"404be498.cbc77c","event":"node.http request.duration.millis","msgid":"1a5f4041.e5a0c","value":"885.579","timestamp":1491409061485}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"404be498.cbc77c","event":"node.http request.size.bytes","msgid":"1a5f4041.e5a0c","value":492,"timestamp":1491409061491}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"404be498.cbc77c","event":"node.http request.send","msgid":"1a5f4041.e5a0c","timestamp":1491409061493}
5 Apr 18:17:41 - [metric] {"level":99,"nodeid":"f78329d7.a270d8","event":"node.delay.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409061495}
5 Apr 18:17:46 - [metric] {"level":99,"event":"runtime.memory.rss","value":104001536,"timestamp":1491409066252}
5 Apr 18:17:46 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409066253}
5 Apr 18:17:46 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":55347176,"timestamp":1491409066254}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"f78329d7.a270d8","event":"node.delay.send","msgid":"1a5f4041.e5a0c","timestamp":1491409071498}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"408b745e.9f3f2c","event":"node.function.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409071498}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"408b745e.9f3f2c","event":"node.function.send","msgid":"1a5f4041.e5a0c","timestamp":1491409071505}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"f259e413.5ae2f8","event":"node.switch.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409071505}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"f259e413.5ae2f8","event":"node.switch.send","msgid":"1a5f4041.e5a0c","timestamp":1491409071506}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"f4d72980.fc5ef8","event":"node.function.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409071506}
5 Apr 18:17:51 - [info] [function:prepare_another_call] [flow2 1a5f4041.e5a0c] URL: http://localhost:1880/gitlab_interface/file?query=string2
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"f4d72980.fc5ef8","event":"node.function.send","msgid":"1a5f4041.e5a0c","timestamp":1491409071508}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"79b169c0.1f8908","event":"node.http request.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409071508}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"f4d72980.fc5ef8","event":"node.function.duration","msgid":"1a5f4041.e5a0c","value":7.91,"timestamp":1491409071515}
5 Apr 18:17:51 - [metric] {"level":99,"nodeid":"408b745e.9f3f2c","event":"node.function.duration","msgid":"1a5f4041.e5a0c","value":11.38,"timestamp":1491409071516}
5 Apr 18:18:01 - [metric] {"level":99,"event":"runtime.memory.rss","value":104493056,"timestamp":1491409081255}
5 Apr 18:18:01 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409081256}
5 Apr 18:18:01 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56854872,"timestamp":1491409081256}
5 Apr 18:18:16 - [metric] {"level":99,"event":"runtime.memory.rss","value":104493056,"timestamp":1491409096258}
5 Apr 18:18:16 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409096259}
5 Apr 18:18:16 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56866328,"timestamp":1491409096261}
5 Apr 18:18:31 - [metric] {"level":99,"event":"runtime.memory.rss","value":104497152,"timestamp":1491409111266}
5 Apr 18:18:31 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409111270}
5 Apr 18:18:31 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56881696,"timestamp":1491409111274}
5 Apr 18:18:46 - [metric] {"level":99,"event":"runtime.memory.rss","value":104525824,"timestamp":1491409126276}
5 Apr 18:18:46 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409126277}
5 Apr 18:18:46 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56954688,"timestamp":1491409126277}
5 Apr 18:19:01 - [metric] {"level":99,"event":"runtime.memory.rss","value":104529920,"timestamp":1491409141279}
5 Apr 18:19:01 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409141280}
5 Apr 18:19:01 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56967392,"timestamp":1491409141281}
5 Apr 18:19:16 - [metric] {"level":99,"event":"runtime.memory.rss","value":104529920,"timestamp":1491409156283}
5 Apr 18:19:16 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409156284}
5 Apr 18:19:16 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56979184,"timestamp":1491409156285}
5 Apr 18:19:31 - [metric] {"level":99,"event":"runtime.memory.rss","value":104529920,"timestamp":1491409171290}
5 Apr 18:19:31 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409171291}
5 Apr 18:19:31 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":56990832,"timestamp":1491409171292}
5 Apr 18:19:46 - [metric] {"level":99,"event":"runtime.memory.rss","value":104529920,"timestamp":1491409186294}
5 Apr 18:19:46 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409186296}
5 Apr 18:19:46 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":57021800,"timestamp":1491409186296}
5 Apr 18:19:51 - [error] [http request:get_file] no response from server
5 Apr 18:19:51 - [error] [http request:get_file] Error: socket hang up
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"79b169c0.1f8908","event":"node.http request.send","msgid":"1a5f4041.e5a0c","timestamp":1491409191542}
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"5c0d3d14.99fc94","event":"node.function.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409191543}
5 Apr 18:19:51 - [warn] [function:prepare_output] [flow2 1a5f4041.e5a0c] Error retrieving the data from the storage
Error: socket hang up : http://localhost:1880/gitlab_interface/file?query=string2
5 Apr 18:19:51 - [warn] [function:init] [flow2 1a5f4041.e5a0c] Let's raise an error: ECONNRESET | Error retrieving the data from the storage
5 Apr 18:19:51 - [info] [function:init] [flow2 1a5f4041.e5a0c] Error raised: ECONNRESET | Error retrieving the data from the storage
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"5c0d3d14.99fc94","event":"node.function.send","msgid":"1a5f4041.e5a0c","timestamp":1491409191549}
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"54690181.c294f","event":"node.http response.receive","msgid":"1a5f4041.e5a0c","timestamp":1491409191550}
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"eb5384b9.2266c8","event":"node.http in.response.time.millis","msgid":"1a5f4041.e5a0c","value":"130973.155","timestamp":1491409191554}
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"eb5384b9.2266c8","event":"node.http in.response.content-length.bytes","msgid":"1a5f4041.e5a0c","value":"105","timestamp":1491409191578}
5 Apr 18:19:51 - [metric] {"level":99,"nodeid":"5c0d3d14.99fc94","event":"node.function.duration","msgid":"1a5f4041.e5a0c","value":35.34,"timestamp":1491409191580}
Error: request aborted
at IncomingMessage.onAborted (...\node-red-0.16.2\node_modules\body-parser\node_modules\raw-body\index.js:269:10)
at emitNone (events.js:67:13)
at IncomingMessage.emit (events.js:166:7)
at abortIncoming (_http_server.js:280:11)
at Socket.serverSocketCloseListener (_http_server.js:293:5)
at emitOne (events.js:82:20)
at Socket.emit (events.js:169:7)
at TCP._onclose (net.js:477:12)
5 Apr 18:20:01 - [metric] {"level":99,"event":"runtime.memory.rss","value":104878080,"timestamp":1491409201297}
5 Apr 18:20:01 - [metric] {"level":99,"event":"runtime.memory.heapTotal","value":84781392,"timestamp":1491409201297}
5 Apr 18:20:01 - [metric] {"level":99,"event":"runtime.memory.heapUsed","value":57427712,"timestamp":1491409201298}
5 Apr 18:20:02 - [info] Stopping flows
When you have two HTTP Request nodes in the same flow, you must ensure you delete the msg.headers property returned by the first node before passing the msg to the second node. This is because the headers from the first node are the response headers, and by passing them to the second node you are asking that node to use those headers in making its request.
You should also make use of the Debug node to see where a flow is getting to; your second call to the gitlab_interface flow is hanging - adding Debug nodes after each node in that flow would tell you where the flow was getting to.
Related
Why does "~$ sudo openvpn ~/<file_name>.ovpn" give error?
I got a .ovpn file for work a couple of weeks ago and at first, everything worked correctly, it was running no problem. When I tried to use it again I got this error <user>#<name>:~$ sudo openvpn ~/<file_name>.ovpn Options error: In [CMD-LINE]:1: Error opening configuration file: /home/<name>/<file_name>.ovpn Use --help for more information. So I tried openvpn --config <file_name>.ovpn and got this <user>#<name>:~$ openvpn --config <file_name>.ovpn Tue Feb 2 11:11:08 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 5 2019 Tue Feb 2 11:11:08 2021 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Tue Feb 2 11:11:08 2021 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Tue Feb 2 11:11:08 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]65.175.70.209:1194 Tue Feb 2 11:11:08 2021 UDP link local: (not bound) Tue Feb 2 11:11:08 2021 UDP link remote: [AF_INET]65.175.70.209:1194 Tue Feb 2 11:11:09 2021 [server] Peer Connection Initiated with [AF_INET]65.175.70.209:1194 Tue Feb 2 11:11:10 2021 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1) Tue Feb 2 11:11:10 2021 Exiting due to fatal error What can I do to fix this? Thanks in advance.
I was able to fix it using an --auth-retry and interact added onto the previous command: <user>#<name>:~$ sudo openvpn --config <file_name>.ovpn --auth-retry interact Wed Feb 3 10:22:13 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 5 2019 Wed Feb 3 10:22:13 2021 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Wed Feb 3 10:22:13 2021 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Wed Feb 3 10:22:13 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]65.175.70.209:1194 Wed Feb 3 10:22:13 2021 UDP link local: (not bound) Wed Feb 3 10:22:13 2021 UDP link remote: [AF_INET]65.175.70.209:1194 Wed Feb 3 10:22:14 2021 [server] Peer Connection Initiated with [AF_INET]65.175.70.209:1194 Wed Feb 3 10:22:15 2021 TUN/TAP device tun0 opened Wed Feb 3 10:22:15 2021 /sbin/ip link set dev tun0 up mtu 1500 Wed Feb 3 10:22:16 2021 /sbin/ip addr add dev tun0 local 172.16.100.185 peer 172.16.100.186 Wed Feb 3 10:22:16 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Wed Feb 3 10:22:16 2021 Initialization Sequence Completed
apache2.service: Control process exited, code=exited status=139
I install apache2 on ubuntu 18.04. This is fresh install with all default configuration. I tried to start apache2 but failed. And this is what I see. # systemctl status apache2.service ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: failed (Result: exit-code) since Wed 2020-03-11 23:17:35 WIB; 13s ago Process: 9151 ExecStart=/usr/sbin/apachectl start (code=exited, status=139) Mar 11 23:17:35 xdn.id systemd[1]: Starting The Apache HTTP Server... Mar 11 23:17:35 xdn.id apachectl[9151]: Segmentation fault Mar 11 23:17:35 xdn.id apachectl[9151]: Action 'start' failed. Mar 11 23:17:35 xdn.id apachectl[9151]: The Apache error log may have more information. Mar 11 23:17:35 xdn.id systemd[1]: apache2.service: Control process exited, code=exited status=139 Mar 11 23:17:35 xdn.id systemd[1]: apache2.service: Failed with result 'exit-code'. Mar 11 23:17:35 xdn.id systemd[1]: Failed to start The Apache HTTP Server. When I check /var/log/apache2/error.log, there is empty. What's wrong with this error?
The "status=139" error must have something to do with having multiple, conflicting versions of PHP enabled. I am running 18.04 and an old PHP site I run only locally ceased to work. I am guessing aptitude installed and enabled php7.2, possibly when I installed kubuntu-desktop a few weeks back. Regardless, I had two versions of PHP enabled: $ cd /etc/apache2/ $ l mods-*/php* -rw-r--r-- 1 root root 867 Jun 9 2017 mods-available/php5.6.conf -rw-r--r-- 1 root root 102 Jun 9 2017 mods-available/php5.6.load -rw-r--r-- 1 root root 867 Mar 2 2017 mods-available/php7.0.conf -rw-r--r-- 1 root root 102 Oct 1 2018 mods-available/php7.0.load -rw-r--r-- 1 root root 855 Jul 7 2017 mods-available/php7.1.conf -rw-r--r-- 1 root root 102 Jul 7 2017 mods-available/php7.1.load -rw-r--r-- 1 root root 855 Feb 8 2019 mods-available/php7.2.conf -rw-r--r-- 1 root root 102 Feb 8 2019 mods-available/php7.2.load lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.conf -> ../mods-available/php5.6.conf lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.load -> ../mods-available/php5.6.load lrwxrwxrwx 1 root root 29 May 28 06:05 mods-enabled/php7.2.conf -> ../mods-available/php7.2.conf lrwxrwxrwx 1 root root 29 May 28 06:05 mods-enabled/php7.2.load -> ../mods-available/php7.2.load In my case, I am fine with using php5.6, because the site is not online and is purely for my local use only. So disabling 7.2 did the trick: sudo a2dismod php7.2 Now my php mods-enabled are less confusing to apache3: $ l mods-*/php* -rw-r--r-- 1 root root 867 Jun 9 2017 mods-available/php5.6.conf -rw-r--r-- 1 root root 102 Jun 9 2017 mods-available/php5.6.load -rw-r--r-- 1 root root 867 Mar 2 2017 mods-available/php7.0.conf -rw-r--r-- 1 root root 102 Oct 1 2018 mods-available/php7.0.load -rw-r--r-- 1 root root 855 Jul 7 2017 mods-available/php7.1.conf -rw-r--r-- 1 root root 102 Jul 7 2017 mods-available/php7.1.load -rw-r--r-- 1 root root 855 Feb 8 2019 mods-available/php7.2.conf -rw-r--r-- 1 root root 102 Feb 8 2019 mods-available/php7.2.load lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.conf -> ../mods-available/php5.6.conf lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.load -> ../mods-available/php5.6.load Naturally for a live site one would want to disable php-5.6 and leave the php7.2 enabled, because you should run the newer version in real life. sudo a2dismod php5.6 sudo a2enmod php7.2 Then the php mods should look like this: $ l mods-*/php* -rw-r--r-- 1 root root 867 Jun 9 2017 mods-available/php5.6.conf -rw-r--r-- 1 root root 102 Jun 9 2017 mods-available/php5.6.load -rw-r--r-- 1 root root 867 Mar 2 2017 mods-available/php7.0.conf -rw-r--r-- 1 root root 102 Oct 1 2018 mods-available/php7.0.load -rw-r--r-- 1 root root 855 Jul 7 2017 mods-available/php7.1.conf -rw-r--r-- 1 root root 102 Jul 7 2017 mods-available/php7.1.load -rw-r--r-- 1 root root 855 Feb 8 2019 mods-available/php7.2.conf -rw-r--r-- 1 root root 102 Feb 8 2019 mods-available/php7.2.load lrwxrwxrwx 1 root root 29 May 29 17:43 mods-enabled/php7.2.conf -> ../mods-available/php7.2.conf lrwxrwxrwx 1 root root 29 May 29 17:43 mods-enabled/php7.2.load -> ../mods-available/php7.2.load Don't forget to resatart the server! systemctl restart apache2 Thanks to Pavel's comment for inspiring this line of research!
I got this error and I fixed it by enabling PHP version 8.0 (current stable) and disabling PHP version 7.4 (old) in my ubuntu 20.04 by these commands: sudo a2dismod php7.4 sudo a2enmod php8.0 sudo service apache2 restart After doing these check your apache status by: sudo systemctl status apache2.service It has to be green and must show you active (running). NOTE: You can do this to any PHP version that you have and want to change.
dnf crashes with segmentation fault
Fedora 4.10.8-200.fc25.i686+PAE dnf is crashing with 'segmentation fault (core dumped)'. I have tried to run 'dnf clean all' without success. When running 'dnf upgrade', this is logged in dnf.log: Apr 30 20:17:21 INFO --- logging initialized --- Apr 30 20:17:21 DDEBUG timer: config: 7 ms Apr 30 20:17:21 DEBUG cachedir: /var/cache/dnf Apr 30 20:17:21 DEBUG Loaded plugins: reposync, Query, noroot, needs-restarting, protected_packages, builddep, playground, config-manager, copr, download, system-upgrade, debuginfo-install, generate_completion_cache Apr 30 20:17:21 DEBUG DNF version: 1.1.10 Apr 30 20:17:21 DDEBUG Command: dnf upgrade Apr 30 20:17:21 DDEBUG Installroot: / Apr 30 20:17:21 DDEBUG Releasever: 25 Apr 30 20:17:21 DDEBUG Base command: upgrade Apr 30 20:17:21 DDEBUG Extra commands: [] Apr 30 20:17:51 DDEBUG repo: downloading from remote: updates, _Handle: metalnk: https://mirrors.fedoraproject.org/metalink?repo=updates-released-f25&arch=i386, mlist: None, urls []. This is logged in 'messages': Apr 30 20:17:51 emil2 audit: ANOM_ABEND auid=0 uid=0 gid=0 ses=10 pid=23817 comm="dnf" exe="/usr/libexec/system-python" sig=11 Apr 30 20:17:51 emil2 kernel: dnf[23817]: segfault at 24 ip b64a9c81 sp bfe10cc0 error 4 in libssl3.so[b6496000+49000] Apr 30 20:17:51 emil2 abrt-hook-ccpp: Process 23817 (system-python) of user 0 killed by SIGSEGV - dumping core Apr 30 20:17:52 emil2 abrt-server: Deleting problem directory ccpp-2017-04-30-20:17:51-23817 (dup of ccpp-2017-04-28-22:02:01-6627) Apr 30 20:17:52 emil2 dbus-daemon[721]: [system] Activating service name='org.freedesktop.problems' requested by ':1.699' (uid=0 pid=23827 comm="/usr/bin/python3 /usr/bin/abrt-action-notify -d /v") (using servicehelper) Apr 30 20:17:52 emil2 dbus-daemon[721]: [system] Successfully activated service 'org.freedesktop.problems' What can I do to troubleshoot?
Got the same problem after upgrade libdb-5.3.28-16 to libdb-5.3.28-24 libdb-utils-5.3.28-16 to libdb-utils-5.3.28-24 Rebuild the rpm db fixed it % rm /var/lib/rpm/__db* % rpm --rebuilddb
Error on startup for mongodb server
totally new to mongodb. I'm trying to install locomotive CMS on my server, which is cool, but I've always used SQL/MySQL so mongo is totally new to me.
I installed all the needed mongodb modules, but when I run: sudo service mongod start I get an error code. When I look in the logs for the error, here is what is output:
Fri Mar 21 18:13:47.186 [initandlisten] MongoDB starting : pid=5053 port=27017 dbpath=/var/lib/mongo 64-bit host=vagrant-centos64.vagrantup.com
Fri Mar 21 18:13:47.186 [initandlisten] db version v2.4.9
Fri Mar 21 18:13:47.186 [initandlisten] git version: 52fe0d21959e32a5bdbecdc62057db386e4e029c
Fri Mar 21 18:13:47.186 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49
Fri Mar 21 18:13:47.186 [initandlisten] allocator: tcmalloc
Fri Mar 21 18:13:47.186 [initandlisten] options: { config: "/etc/mongod.conf", dbpath: "/var/lib/mongo", fork: "true", logappend: "true", logpath: "/var/log/mongo/mongod.log", pidfilepath: "/var/run/mo$
Fri Mar 21 18:13:47.192 [initandlisten] journal dir=/var/lib/mongo/journal
Fri Mar 21 18:13:47.192 [initandlisten] recover : no journal files present, no recovery needed
Fri Mar 21 18:13:47.192 [initandlisten]
Fri Mar 21 18:13:47.192 [initandlisten] ERROR: Insufficient free space for journal files
Fri Mar 21 18:13:47.192 [initandlisten] Please make at least 3379MB available in /var/lib/mongo/journal or use --smallfiles
Fri Mar 21 18:13:47.192 [initandlisten]
Fri Mar 21 18:13:47.193 [initandlisten] exception in initAndListen: 15926 Insufficient free space for journals, terminating
Fri Mar 21 18:13:47.193 dbexit:
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: going to close listening sockets...
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: going to flush diaglog...
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: going to close sockets...
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: waiting for fs preallocator...
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: lock for final commit...
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: final commit...
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: closing all files...
Fri Mar 21 18:13:47.193 [initandlisten] closeAllFiles() finished
Fri Mar 21 18:13:47.193 [initandlisten] journalCleanup...
Fri Mar 21 18:13:47.193 [initandlisten] removeJournalFiles
Fri Mar 21 18:13:47.193 [initandlisten] shutdown: removing fs lock...
Fri Mar 21 18:13:47.193 dbexit: really exiting now
Also, I run: sudo service mongod status and the output is mongod is stopped so I know it's not running.
Following the stack, it looks like the error has something to do with insufficient space, but my server has 15gb free and im running sudo, so i know it's not a permission error....how can I allocate more space...or better yet, what should i allocate more space to?
Any help is appreciated.
Add smallfiles = true to "/etc/mongodb.conf". Now try to start the service, I assume this should fix the issue!! Set to true to modify MongoDB to use a smaller default data file size. Specifically, smallfiles reduces the initial size for data files and limits them to 512 megabytes. The smallfiles setting also reduces the size of each journal files from 1 gigabyte to 128 megabytes.
mod_wsgi is compiled in one version and running in a different version even after following the given steps
I am getting an error when I run the apache server through my client after going through the log I understood that the mod_wsgi uses python 2.6 during compiling and uses python 2.7 for running. After some research in the Internet I followed the below steps: You have to recompile mod-python and/or mod-wsgi. Remove mods apt-get remove libapache2-mod-python libapache2-mod-wsgi Get dependencies apt-get build-dep libapache2-mod-python libapache2-mod-wsgi Build mod-python mkdir /tmp/python cd /tmp/python apt-get source libapache2-mod-python cd libapache2-mod-python-[x.x.x] dpkg-buildpackage -rfakeroot -b Build mod-wsgi mkdir /tmp/wsgi cd /tmp/wsgi apt-get source libapache2-mod-wsgi cd mod-wsgi-[x.x.x] dpkg-buildpackage -rfakeroot -b Install newly compiled packages dpkg -i /tmp/python/libapache2-mod-python-[x.x].deb /tmp/wsgi/libapache2-mod-wsgi-[x.x].deb It was of no use, now the version has changed to 3.2, I am worried about the space being consumed through the above steps and now the compiling python has changes to python 3.2 from 2.6 but the python used for running is still 2.7. please help me with what to do ? to get back my apache server running successfully. error.log:::: [Wed Aug 21 11:48:11 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+. [Wed Aug 21 11:48:11 2013] [warn] mod_wsgi: Runtime using Python/2.7.3. [Wed Aug 21 11:48:11 2013] [notice] Apache/2.2.22 (Ubuntu) mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations [Wed Aug 21 11:48:36 2013] [notice] caught SIGTERM, shutting down [Wed Aug 21 22:48:29 2013] [error] child process 1226 still did not exit, sending a SIGKILL [Wed Aug 21 22:48:30 2013] [notice] caught SIGTERM, shutting down [Wed Aug 21 22:56:17 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+. [Wed Aug 21 22:56:17 2013] [warn] mod_wsgi: Runtime using Python/2.7.3. [Wed Aug 21 22:56:17 2013] [notice] Apache/2.2.22 (Ubuntu) mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations [Thu Aug 22 01:32:12 2013] [notice] caught SIGTERM, shutting down [Thu Aug 22 01:32:26 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+. [Thu Aug 22 01:32:26 2013] [warn] mod_wsgi: Runtime using Python/2.7.3. [Thu Aug 22 01:32:26 2013] [notice] Apache/2.2.22 (Ubuntu) mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations [Thu Aug 22 04:04:48 2013] [notice] child pid 11212 exit signal Segmentation fault (11) [Thu Aug 22 04:04:48 2013] [notice] caught SIGTERM, shutting down [Thu Aug 22 04:04:56 2013] [notice] mod_python: Creating 8 session mutexes based on 6 max processes and 25 max threads. [Thu Aug 22 04:04:56 2013] [notice] mod_python: using mutex_directory /tmp [Thu Aug 22 04:04:56 2013] [warn] mod_wsgi: Compiled for Python/3.2.3. [Thu Aug 22 04:04:56 2013] [warn] mod_wsgi: Runtime using Python/2.7.3. [Thu Aug 22 04:04:56 2013] [notice] Apache/2.2.22 (Ubuntu) mod_python/3.3.1 Python/2.7.3 mod_wsgi/3.3 configured -- resuming normal operations Thank you
Don't load mod_python and mod_wsgi at the same time if you don't need to. They are likely compiled against different Python versions. See the following for an explanation of the mismatch you are seeing. http://code.google.com/p/modwsgi/wiki/InstallationIssues#Python_Version_Mismatch If you do need both, they must both be compiled for the same version. These days there is generally no good reason to be using mod_python for new projects.
Just to add I have uninstalled libapache2-mod-python sudo apt-get remove libapache2-mod-python which I have installed then I have overcome the above error [Thu Aug 22 01:32:26 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+. [Thu Aug 22 01:32:26 2013] [warn] mod_wsgi: Runtime using Python/2.7.3.