I'm having some troubles with statsD from etsy, and seeing that i'm not really experienced with javascript I thought I should ask a question maybe somebody has encountered this error before, because sadly this time google hasn't been that helpful.
The troubles have started a couple of days ago when I decided to restart the node process that was keeping statsD up, when after the restart it just wouldn't start. It gives me the following output:
2 Jul 03:02:08 - reading config file: /opt/statsd/statsd/psrkConfig.js
2 Jul 03:02:08 - server is up
2 Jul 03:02:08 - Loading backend: ./backends/graphite
events.js:72
throw er; // Unhandled 'error' event
^
Error: bind Unknown system errno 92
at errnoException (dgram.js:440:11)
at dgram.js:207:28
at dns.js:72:18
at process._tickCallback (node.js:415:13)
First of all I think I should have described a little my environment. I'm using gentoo as an OS, I have net-libs/nodejs-0.10.10 installed on the system(was actually 0.10.8 but I upgraded in my search for the problem resolution) and I have cloned the latest etsy/statsD repo from git. I have also tried with the npm version of statsD but got the same behaviour.
I tried following the program with strace and got to the error, but I have no idea how to procede forward. The syscall that fails from what I'm guessing is the following one:
setsockopt(11, SOL_SOCKET, 0xf /* SO_??? */, [1], 4) = -1 ENOPROTOOPT (Protocol not available) <0.000009>
but it has to be called from somewhere inside statsD (making it easier to debug), and I could not find it.
I would appreciate any kind of little help or pointers, because I'm guessing the error comes form the node.js libraries and I'm pretty clueless about them. Thank you.
similar to #user1135, had trouble with binding to UDP sockets on a recent build of debian/testing. we commented out the #ifdef sections in udp.c and recompiled to fix the problem.
I had a similar problem recently, also on Gentoo Linux. It so happened I had the 3.9 linux headers installed but was still running an older kernel. This caused SO_REUSEPORT to be defined when building node.js (specifically uv). Going back to the proper header version or doing #undef SO_REUSEPORT inside of deps/uv/src/unix/udp.c should fix it. Also upgrading to a 3.9+ kernel would do it.
Related
I am stuck in this problem. I am running cypress tests. When I run locally, it runs smoothly. when I run in circleCI, it throws error after some execution.
Here is what i am getting:
[334:1020/170552.614728:ERROR:bus.cc(392)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[334:1020/170552.616006:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[334:1020/170552.616185:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[521:1020/170552.652819:ERROR:gpu_init.cc(441)] Passthrough is not supported, GL is swiftshader
Current behavior:
When I run my specs headless on the circleCI, Cypress closed unexpectedly with a socket error.
Error message:
The Test Runner unexpectedly exited via a exit event with signal
SIGSEGV
Please search Cypress documentation for possible solutions:
https://on.cypress.io
Platform: linux (Debian - 10.5)
Cypress Version: 8.6.0
Issue resolved by reverting back cypress version to 7.6.0.
I had this same issue on within our Azure builds as well. We only recently migrated from Cypress 8.4.0. Going back to that has solved the problem.
downgrade the cypress by running npm install cypress#7.6.0
Downgrade of cypress to 8.3.0 worked for me to solve that, you dont need to go to previous versions.
npm install cypress#8.3.0
SIGSEGV means a segmentation fault error. Read all about it here.
"In practice, a segfault occurs when your program breaks some
fundamental rule set by the operating system. In that case, the
operating system sends your process a signal (SIGSEGV on Mac & Linux,
STATUS_ACCESS_VIOLATION on Windows), and typically the process shuts
down immediately."
This blog post also goes into detail about how this can occur, even if you don't directly interact with the operating system (since we're writing JavaScript). Please read it on the original author's site for context.
But in short - you are likely encountering this error because
a. you upgraded Cypress while on an old version of NodeJS, or
b. you upgraded NodeJS, while you have Cypress code that is directly or indirectly incompatible (this could be your own code, or one of its dependencies) with that NodeJS version
Since SIGSEGV is a complete shutdown, you have no stack trace or debug information to guide you. So you have to debug the old fashioned way, turning tests and/or dependencies on or off to locate the problem in your code.
I've created a client react application using create-react-app. It talks to a node server running an express api. In development everything is working great and was getting ready to deploy.
When running npm run build I get no errors whatsoever either, everything seems to be working great. When build finishes it suggest to run serve -s build , I do this and navigate to my localhost:5000, the first console.logs from my app show up but then suddenly i throws a seemingly simple javascript error:
TypeError: "e.forEach is not a function"
me InboundTab.js:27
me InboundTab.js:36
React 7
unstable_runWithPriority scheduler.production.min.js:270
React 5
getArrivals ArrivalState.js:39
l runtime.js:45
_invoke runtime.js:264
t runtime.js:98
l runtime.js:45
t runtime.js:137
t runtime.js:147
react-dom.production.min.js:4636:12
React 5
unstable_runWithPriority scheduler.production.min.js:270
React 4
unstable_runWithPriority scheduler.production.min.js:270
React 5
getArrivals ArrivalState.js:39
l runtime.js:45
_invoke runtime.js:264
t runtime.js:98
l runtime.js:45
t runtime.js:137
t runtime.js:147
I've been looking all over the internet but can't find any clues on what's going on here. Most sites talk about errors during the build process or a site not showing at all but this is neither. Googling the error seems to say this is some ES6 issue, but I'm running firefox 73 so I'd expect no issues on that front.
As extra info this is my first time trying to deploy react. Funny enough I'd only done small projects so far running locally so I am pretty sure I'm missing something obvious in the build process.
Any help, tips on where to loop will be most appreciated. Thanks!
Answering my own question. I guess I just needed to re-read this error with the nice syntax highlight because the filename and line location took me to the right place.
On my client's api calls I set up the server url as:
const API_SERVER =
process.env.NODE_ENV === "development"
? "http://localhost:4200"
: "http://example.com";
but my example.com isn't setup yet so the error came from not being able to reach the server. Changing the example.com to localhost and re-building made things work.
I'm trying to transfer my application to a new machine. It works on the old machine perfectly, and I have been trying to copy the settings as closely as possible, but there is something missing. This is the error I'm getting:
Unhandled rejection SequelizeConnectionError: Handshake inactivity timeout
at Handshake._callback (/Applications/MAMP/htdocs/dashboard-server/node_modules/sequelize/lib/dialects/mysql/connection-manager.js:63:20)
at Handshake.Sequence.end (/Applications/MAMP/htdocs/dashboard-server/node_modules/mysql/lib/protocol/sequences/Sequence.js:96:24)
at /Applications/MAMP/htdocs/dashboard-server/node_modules/mysql/lib/protocol/Protocol.js:393:18
at Array.forEach (native)
at /Applications/MAMP/htdocs/dashboard-server/node_modules/mysql/lib/protocol/Protocol.js:392:13
at doNTCallback0 (node.js:417:9)
at process._tickCallback (node.js:346:13)
Thoughts?
Just confirmed the problem is either Sequelize / mysql in conjunction with Node 4.2.0 after manually re-installing 4.1.1 my problems went away.
Downgrade to Node 4.1.x or wait for a patch/fix/etc to solve your issues.
Additional Information
The bug has been reported here on the node-mysql repository issue tracker. Seems someone regressed something in Node 4.2.0 and it wasn't caught. Here's the pull request to fix it which was merged in and is in the candidate for 4.2.1.
Update Oct 13th, 2015
Node 4.2.1 was just released (Changelog) containing the aforementioned fix. Upgrading to 4.2.1 should also fix your problems.
I'm trying to run Ghostdriver inside my Openshift server. As i run this command:
./phantomjs --webdriver=15002
It says:
PhantomJS is launching GhostDriver...
[ERROR - 2014-08-01T04:14:21.160Z] GhostDriver - main.fail - {"message":"Could not start Ghost Driver","line":82,"sourceId":139887801789952,"sourceURL":":/ghostdriver/main.js","stack":"Error: Could not start Ghost Driver\n at :/ghostdriver/main.js:82","stackArray":[{"sourceURL":":/ghostdriver/main.js","line":82}]}
$ ./phantomjs --version
1.9.8
Please help me out, I'm getting this error from 10 Days. I searched everything and googled everything. nothing is sorted me out :( I'm much upset :(
Help surely would be appreciated!!
OpenShift doesn't allow binding the localhost address; there is a patch to allow GhostDriver to bind any specified IP (currently it always binds to localhost no matter what), but it still hasn't made it in the PhantomJS source tree and binary distributions.
In order to use PhantomJS + GhostDriver on OpenShift I recompiled it after applying the patch, you can find it here: https://paolobernardi.wordpress.com/2015/02/25/phantomjs-with-ghostdriver-on-openshift/
Check the Port Number while running the below command. Might be your port say 5555 is already in used. So change that if you get this "Could not start Ghost Driver" error
phantomjs --webdriver=5555
From the documentation it looks like you should be able to do something like this:
./phantomjs --webdriver=$OPENSHIFT_NODEJS_IP:15002
You may have to actually type in your ip address there, not sure if that env variable will populate correctly..
http://phantomjs.org/api/command-line.html
--webdriver starts in 'Remote WebDriver mode' (embedded GhostDriver): '[[:]]' (default '127.0.0.1:8910')
I have not been able to make Paolo Bernardi's patch work, I always catched a segmentation fault. So I re-compiled it on an RHEL machine, and this one worked for me: http://christophe-maillard.com/phantomjs-1.9.8.patched/phantomjs.tar.gz
PS: see Trying to run PhantomJS on OpenShift: cannot patch GhostDriver so that it can bind on the server IP address
Make sure the phantomjs process isn't already running
ps -ef | grep phantom
I installed Meteor for windows from here :
http://win.meteor.com
The server crashes almost every time I try to make live code push.
I would then have to end the mongod.exe process and run 'meteor reset' and 'meteor' to start it up back again.
Here are the logs:
=> Meteor server restarted
events.js:71
throw arguments[1]; // Unhandled 'error' event
^
Error: This socket is closed.
at Socket._write (net.js:519:19)
at Socket.write (net.js:511:15)
at Socket.HttpProxy.proxyWebSocketRequest.reverseProxy.incoming.socket.on.listeners.onOutgoing (C:\Program Files\Meteor\lib\node_modules\http-proxy\lib\node-http-proxy\http-proxy.js:515:35)
at Socket.EventEmitter.emit (events.js:96:17)
at TCP.onread (net.js:397:14)
Anyone on the same boat? I read from here https://github.com/meteor/meteor/issues/513 that this has been an open issue for over 6 months.
Someone's got any workaround? Help appreciated.
The EADDRINUSE issue was fixed in 0.6.3.1-rev4, but please update to version 0.6.4 as this problem seems to have resolved the other issue by the update to the http-proxy package.
For MSI downloads see https://github.com/sdarnell/meteor/wiki/Windows
Should also appear on http://win.meteor.com soon
This is a known issue with windows for meteor : https://github.com/sdarnell/meteor/issues/7. The one on meteor's github repo might also be related. I have it too! Hopefully they sort it out soon!. Just ctrl+c to stop your server before you edit code and get it back up after you're done.
Even if you start it after this sometimes you could also get an ADDRINUSE error, which is quite frustrating.