Live debugging a frozen nodejs program - node.js

I have a nodejs process running but after a couple hours it keeps just getting stuck in some infinite loop somewhere, no error message or timeout message right now. So I am trying to live debug the frozen program:
On the command line I run $ top to get the process id of my node program, then run these commands to go into the node debug mode:
//my node PID=2599
$ kill -SIGUSR1 2599
$ node inspect -p 2599
debug> pause
break in internal/timers.js:483
481
482 function processTimers(now) {
>483 debug('process timer lists %d', now);
484 nextExpiry = Infinity;
485
debug> bt
#0 processTimers internal/timers.js:483:4
debug>
The two debug commands I've used so far are bt and pause, and I can see it points to a line in internal/timers.js, but where can I fine the location of this file? I've searched for the filename and code in my project but can't find it anywhere. I am running this version:
$ npm -v
7.12.0
$ node -v
v14.16.1

Related

arangodb starter mode does not start

I have d/l'd arangodb3-linux-3.9.2 from GIT on Centos 7. I created a database dir and ran the README instructions for a standalone start. The first time it runs, I get 100 failures, the key INFO log lines seem to be
... [INFO] server started component=arangodb pid=49827 type=single
... [INFO] Wait on 49827 returned component=arangodb exit-status=1 trap-cause=-1
It creates the log file, setup.json and a single8529 dir in the database dir I sped'd. Is it just taking too long to start? The whole 100 fails take about 1 or 2 seconds.
If I try to run it again with the same README instructions, the next time I get this error:
... [FATAL] Failed to run service error="open /.../single8529/data/ENGINE: no such file"
I have also tried with --starter.host 127.0.0.1 -- to simplify
Also I and can confirm that port 8529 is open
I couldn't get arangodb 'starter' according to their README to work, but this does start the server:
arangod --database.directory MYDIR --rocksdb.max-background-jobs 4

mpirun launching a runtime script for thread binding

Running a program in a MPI process, which exec file is myapp_mpi. The command line below launches the app correctly
mpirun --bind-to none -np 128 myapp_mpi apprun -resethway -noconfout -nsteps 8000 -s benchData.tpr -cpo state.cpt -e ener.edr -dlb no -pin off -v
I now wish to constrain the thread binding with a script pin.sh. The command line below would then produce an error.
mpirun --bind-to none -np 128 pin.sh myapp_mpi apprun -resethway -noconfout -nsteps 8000 -s benchData.tpr -cpo state.cpt -e ener.edr -dlb no -pin off -v
I get the following error
--------------------------------------------------------------------------
Open MPI tried to fork a new process via the "execve" system call but
failed. Open MPI checks many things before attempting to launch a
child process, but nothing is perfect. This error may be indicative
of another problem on the target host, or even something as silly as
having specified a directory for your application. Your job will now
abort.
Local host: machine001
Working dir: /home/user/myapp/bin
Application name: /home/user/myapp/bin/pin.sh
Error: Exec format error
--------------------------------------------------------------------------
mpirun: Forwarding signal 18 to job
mpirun: Forwarding signal 18 to job
--------------------------------------------------------------------------
mpirun was unable to start the specified application as it encountered an
error:
Error code: 1
Error name: (null)
Node: machine001
when attempting to start process rank 0.
--------------------------------------------------------------------------
125 total processes failed to start
File locations are good, a priori. Any clue ?

Azure-IoT - Raspberry pi3 Forever script exited with code: 7

I'm running a forever script sending data from raspberry pi 3 to azure-iot-hub, using the following,
root#raspberrypi3:~# forever start /home/pi/azure/iam/ble_azure.js
After working for about 1.5 days, I stopped getting messages at auzre-iot-hub, when I checked forever list I got the following:
root#raspberrypi3:~# forever list
info: Forever processes running
data: uid command script forever pid id logfile uptime
data: [0] NWgI /usr/bin/nodejs /home/pi/azure/iam/ble_azure.js 8990 3784 /root/.forever/NWgI.log 0:21:17:38.742
When I checked the log file I get this error message:
/home/pi/azure/iam/node_modules/applicationinsights/AutoCollection/Exceptions.js:27
throw error;
^
NotConnectedError: mqtt.js returned client disconnecting error
at translateError (/home/pi/azure/iam/node_modules/azure-iot-device-mqtt/lib/mqtt-translate-error.js:25:11)
at MqttTwinReceiver._handleError (/home/pi/azure/iam/node_modules/azure-iot-device-mqtt/lib/mqtt-twin-receiver.js:201:42)
at /home/pi/azure/iam/node_modules/azure-iot-device-mqtt/lib/mqtt-twin-receiver.js:64:18
at MqttClient._checkDisconnecting (/home/pi/azure/iam/node_modules/mqtt/lib/client.js:314:7)
at MqttClient.subscribe (/home/pi/azure/iam/node_modules/mqtt/lib/client.js:423:12)
at /home/pi/azure/iam/node_modules/azure-iot-device-mqtt/lib/mqtt-twin-receiver.js:62:22
at _combinedTickCallback (internal/process/next_tick.js:73:7)
at process._tickCallback (internal/process/next_tick.js:104:9)
error: Forever detected script exited with code: 7
error: Script restart attempt #34
state has changed poweredOn
started scanning
[IoT hub Client] Connect error: mqtt.js returned premature close error
Through the log file, mqtt error keeps happening multiple times and forever handled it successfully, what I can't understand why after 1.5 days, I get this error:
**error: Forever detected script exited with code: 7
error: Script restart attempt #34**
Also why I keep getting such mqtt error, why it keeps disconnecting?
**NotConnectedError: mqtt.js returned client disconnecting error**
Forever --version
v0.15.3
root#raspberrypi3:~# uname -a
Linux raspberrypi3 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux
Thanks
If you're using Client.fromConnectionString to instantiate the client object the SDK disconnects and reconnects every 45 minutes to renew the shared access signature token. (it doesn't happen with AMQP that uses a different authentication mechanism). It might be that when re-establishing the connection the client hits this "premature close" error that we've been tracking in this issue.
There are 2 things that could help limit potential errors linked to disconnecting/reconnecting:
Use X509 certificates instead of connection strings to authenticate.
Create a client object using Client.fromSharedAccessSignature and build a long-lived signature that does not require disconnecting and reconnecting as often.
Last but not least, the next release of the SDK (1.2.0) will include a retry/reconnect logic that is way more robust than what was there before. I'll update the issue to point to it when it is released.

NodeJS Forever package minUptime and spinSleepTime warnings

I'm trying to run the forever function for node.js but I get below warnings;
C:\serv>forever start SERVER.js
warn: --minUptime not set. Defaulting to: 1000ms
warn: --spinSleepTime not set. Your script will exit if it does not stay up f
or at least 1000ms
info: Forever processing file: SERVER.js
How to set --minUptime and --spinSleepTime to remove these warnings
Installed forever package with npm install forever -g
These are only warnings. You could go on ignoring them, if you want.
But if you want to explicitly set them, forever --help tells you how to do so. Just start forever with:
forever start --minUptime 1000 --spinSleepTime 1000 SERVER.js
The documentation is not very exhaustive, a bit of additional information.
In the following examples we will use two scripts:
fail-fast.js:
process.exit(1);
fail-slow.js:
setTimeout(() => { process.exit(1); }, 2000);
1) using defaults
forever fail-fast.js
fail-fast.js script will execute only once, then no other start attempts will be made.
forever fail-slow.js
fail-slow.js script will be restarted indefinitely, as it stays up more than 1000ms (default value of minUptime if not specified). You can limit the number of restarts with the -m parameter.
2) setting only minUptime
forever --minUptime 10000 fail-fast.js
forever --minUptime 10000 fail-slow.js
Both fail-fast.js and fail-slow.js will be never be restarted, because we extended minUptime to 10 seconds and now fail-slow.js is considered spinning.
3) setting spinSleepTime
Whenever you set spinSleepTime (with or without minUptime), your process will restart even if it is considered 'spinning'.
forever --spinSleepTime 30000 fail-fast.js
forever --spinSleepTime 30000 fail-slow.js
Both scripts will be restarted forever, waiting spinSleepTime milliseconds between restarts.
In short:
When stop
if hadRunTime >= minUptime
restart
else if spinSleepTime != 0
wait spinSleepTime
restart
else
stop and no restart
#Megadix The answer has something wrong with spinSleepTime.
fail-fast.js will restart wating spinSleepTime,but fail-slow.js will restart immediately,no waiting! It can be Proved by:
console.log((new Date()).getTime());
setTimeout(() => {
process.exit(1);
}, 2000);
output like:
1468812185697
error: Forever detected script exited with code: 1
error: Script restart attempt #1
1468812187766
error: Forever detected script exited with code: 1
error: Script restart attempt #2
1468812189834
error: Forever detected script exited with code: 1
error: Script restart attempt #3
1468812191901
error: Forever detected script exited with code: 1
error: Script restart attempt #4
1468812193977
error: Forever detected script exited with code: 1
error: Script restart attempt #5
1468812196039
error: Forever detected script exited with code: 1
error: Script restart attempt #6
1468812198107
error: Forever detected script exited with code: 1
error: Script restart attempt #7
1468812200172
error: Forever detected script exited with code: 1
forever start --minUptime 1234 --spinSleepTime 3421 SERVER.js
https://github.com/nodejitsu/forever#usage
I'm assuming you are using express module that is way after you using - forever start SERVER.js - your server is not running, because express module run server in path ./bin/www - so you should use this command - forever start ./bin/www --name="SERVER" - name is the name of your js file, by default app.js

heimcontrol.js Node/Mongodb: 'events.js:2817: Uncaught Error: Cannot open /dev/'

I have been struggling for a week trying to figure out what went wrong. I had this running fine from outside my house and controlling an led on a breadboard. When I restarted my pi and attempted to run 'node heimcontrol.js', I am greeted with 'info - socket.io started' (expected), and two instances of 'events.js:2817: Uncaught Error: Cannot open /dev/' and no return of listening on port. I've checked and changed my permissions of /dev/ to 'drwxr-xr-x 12 pi root 3100 Sep 28 15:58 dev'. I know 777 isn't the best practice, but I was trying to see if that was the issue. I've tried to locate the events.js to dig deeper, but no luck. What should I check next? I've run out of ideas.
node v0.10.2
mongo v2.1.1
pi#raspberrypi ~/heimcontrol.js $ node heimcontrol.js
info - socket.io started
events.js:2817: Uncaught Error: Cannot open /dev/
events.js:2817: Uncaught Error: Cannot open /dev/
Thank you very much in advance.
Edit 01: I pointed my Pi browser to 127.0.0.1:8080 and was greeted with a page 'Motion 3.2.12 Running [1] Threads' and a hyperlink 'All' which leads to settings. I am assuming that I created a video module in Heimcontrol and did not finish the setup since Motion detect my camera (RPi camera module). Not familiar with Motion, maybe someone can help guide me.

Resources