Node red on-close event does not wait for async function to finish - node.js

According to the documentation
https://nodered.org/docs/creating-nodes/node-js
when Node-red (or the specific node in question) closes down,the "close" event is called and if a listener is registered with a parameter it should wait for done() before completely stopping.
this.on('close', function(done) {
doSomethingWithACallback(function() {
done();
});
});
It doesn't work for me though. My mistake, I'm sure, but I don't see where. The following code displays the first "Closing" entry in the log, but not the second entry "Waited enough. Actually finishing now.":
node.on("close", function(done) {
node.log('Closing.');
setTimeout(function(){
node.log('Waited enough.Actually finishing now.');
done();
},5000);
});
Can someone please give me a pointer ?
Using:
Node-red 0.17.5
node.js 6.14.1
Edit: output log added below
pi#raspberrypi:~ $ node-red-start
Start Node-RED
Once Node-RED has started, point a browser at http://192.168.1.17:1880
On Pi Node-RED works better with the Firefox or Chrome browser
Use node-red-stop to stop Node-RED
Use node-red-start to start Node-RED again
Use node-red-log to view the recent log output
Use sudo systemctl enable nodered.service to autostart Node-RED at every boot
Use sudo systemctl disable nodered.service to disable autostart on boot
To find more nodes and example flows - go to http://flows.nodered.org
Starting as a systemd service.
Started Node-RED graphical event wiring tool..
16 Apr 10:11:27 - [info]
Welcome to Node-RED
===================
16 Apr 10:11:27 - [info] Node-RED version: v0.17.5
16 Apr 10:11:27 - [info] Node.js version: v6.14.1
16 Apr 10:11:27 - [info] Linux 4.14.30-v7+ arm LE
16 Apr 10:11:30 - [info] Loading palette nodes
16 Apr 10:11:47 - [info] Dashboard version 2.7.0 started at /ui
16 Apr 10:11:50 - [info] Settings file : /home/pi/.node-red/settings.js
16 Apr 10:11:50 - [info] User directory : /home/pi/.node-red
16 Apr 10:11:50 - [info] Flows file : /home/pi/.node-red/flows_raspberrypi.json
16 Apr 10:11:50 - [info] Server now running at http://127.0.0.1:1880/
16 Apr 10:11:51 - [info] Starting flows
16 Apr 10:11:51 - [info] Started flows
Stopping Node-RED graphical event wiring tool....
16 Apr 10:12:06 - [info] Stopping flows
16 Apr 10:12:06 - [info] [simple-queue:queue1] Closing.
Stopped Node-RED graphical event wiring tool..

You are hitting a bug that was fixed in Node-RED 0.18.
Prior to Node-RED 0.18, the code that handled the shutdown of the runtime did not wait for the all of the node close handlers to complete before the process was terminated.

Related

Elastisearch Enabling Remote Connection - Crashes AFTER Change*

I just installed filebeat, logstash, kibana and elasticsearch all running smoothly just to trial this product out for additional monthly reports/monitoring and noticed every time I try to change the "/etc/elasticsearch/elasticsearch.yml" config file for remote web access it'll basically crash the service every time I make the change.
Just want to say I'm new to the forum and this product, and my end goal for this question is to figure out how to allow remote connections to access elastisearch as I guinea pig and test without crashing elasticsearch.
For reference here is the error code when I run the 'sudo systemctl status elasticsearch' query:
Dec 30 07:27:37 ubuntu systemd[1]: Starting Elasticsearch...
Dec 30 07:27:52 ubuntu systemd-entrypoint[4067]: ERROR: [1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.
Dec 30 07:27:52 ubuntu systemd-entrypoint[4067]: bootstrap check failure [1] of [1]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.se>
Dec 30 07:27:52 ubuntu systemd-entrypoint[4067]: ERROR: Elasticsearch did not exit normally - check the logs at /var/log/elasticsearch/elasticsearch.log
Dec 30 07:27:53 ubuntu systemd[1]: elasticsearch.service: Main process exited, code=exited, status=78/CONFIG
Dec 30 07:27:53 ubuntu systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
Dec 30 07:27:53 ubuntu systemd[1]: Failed to start Elasticsearch.
Any help on this is greatly appreciated!

Starting a dead node of Percona XTradb cluster

We have a Xtradb cluster with three nodes. There is one node, which was not properly stopped and won't start. The other two nodes are correctly working and responding. The only thing in logs is this:
-- Unit mysql.service has begun starting up.
Aug 25 04:40:45 percona-prod-perconaxtradb-vm-0 /etc/init.d/mysql[2503]: MySQL PID not found, pid_file detected/guessed: /var/run/mysql
Aug 25 04:40:52 percona-prod-perconaxtradb-vm-0 mysql[2462]: Starting MySQL (Percona XtraDB Cluster) database server: mysqld . . . . .
Aug 25 04:40:52 percona-prod-perconaxtradb-vm-0 mysql[2462]: failed!
Aug 25 04:40:52 percona-prod-perconaxtradb-vm-0 systemd[1]: mysql.service: control process exited, code=exited status=1
Aug 25 04:40:52 percona-prod-perconaxtradb-vm-0 systemd[1]: Failed to start LSB: Start and stop the mysql (Percona XtraDB Cluster) daem
-- Subject: Unit mysql.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
In /var/lib/mysql/wsrep_recovery.qEEkjd we found this:
2018-08-25T05:49:31.055887Z 0 [ERROR] Found 20 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.
2018-08-25T05:49:31.055892Z 0 [ERROR] Aborting
2018-08-25T05:49:31.055901Z 0 [Note] Binlog end
We would like to completely drop these 20 prepared transactions.
The other two nodes are consistent and working, so it would be enough to tell this node "ignore your state and sync with other nodes".
In the end we removed the /data folder on the dead node and restarted the node. The node then started SST replication - which takes a long time and the only progress one can see is checking the growing size of the folder. But then it worked.

BBB Palette not displayed on Node-Red on Beaglebone Black Wireless

My node-red installation does not display the nodes needed for accessing beaglebone IOs (node-red-node-beaglebone).
In my opinion error is actually caused because node-red-node-beaglebone loads octalbonescript which needs serialport, and something requests serialPort instead of serialport there.
I already tried the preinstalled, stable and lts nodejs version. Additionally npm#2 and npm#3 for installing the nodes. The .node-red folder was also already deleted by me and the node-red-node-beaglebone packaged got installed in the .node-red/node_modules folder started from scrach.
root#beaglebone:/etc# cat debian_version
8.7
root#beaglebone:~# npm -v
2.15.11
root#beaglebone:~# uname -a
Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux
root#beaglebone:~# export AUTO_LOAD_CAPE=0 #optional
root#beaglebone:~# node-red-pi
1487183133432 Board Looking for connected device
15 Feb 19:25:34 - [info]
Welcome to Node-RED
===================
15 Feb 19:25:34 - [info] Node-RED version: v0.16.2
15 Feb 19:25:34 - [info] Node.js version: v6.9.5
15 Feb 19:25:34 - [info] Linux 4.4.30-ti-r64 arm LE
15 Feb 19:25:44 - [info] Loading palette nodes
15 Feb 19:25:57 - [warn] ------------------------------------------------------
15 Feb 19:25:57 - [warn] [bbb] ReferenceError: serialPort is not defined +seems to be the problem
15 Feb 19:25:57 - [warn] ------------------------------------------------------
15 Feb 19:25:57 - [info] Settings file : /root/.node-red/settings.js
15 Feb 19:25:57 - [info] User directory : /root/.node-red
15 Feb 19:25:57 - [info] Flows file : /root/.node-red/flows_beaglebone.json
15 Feb 19:25:57 - [info] Creating new flow file
15 Feb 19:25:57 - [debug] loaded flow revision: 513fd923d68021b8ee98fcb250470340
15 Feb 19:25:57 - [debug] red/runtime/nodes/credentials.load : no user key present
15 Feb 19:25:57 - [debug] red/runtime/nodes/credentials.load : using default key
15 Feb 19:25:57 - [info] Starting flows
15 Feb 19:25:57 - [info] Started flows
15 Feb 19:25:57 - [info] Server now running at http://127.0.0.1:1880/

Elasticsearch connection error in Ubuntu 16.4

In my ubuntu machine when I run the command curl -X GET 'http://localhost:9200' to test connection it show following message.
curl: (7) Failed to connect to localhost port 9200: Connection refused
When i check server status with sudo systemctl start elasticsearch it show following message.
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2016-11-20 16:32:30 BDT; 44s ago
Docs: http://www.elastic.co
Process: 8653 ExecStart=/usr/share/elasticsearch/bin/elasticsearch -p ${PID_DIR}/elasticsearch.pid --quiet -Edefault.path.logs=${LOG_DIR} -Edefa
Process: 8649 ExecStartPre=/usr/share/elasticsearch/bin/elasticsearch-systemd-pre-exec (code=exited, status=0/SUCCESS)
Main PID: 8653 (code=exited, status=1/FAILURE)
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,579 main ERROR Null object returned for RollingFile in Appenders.
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,579 main ERROR Null object returned for RollingFile in Appenders.
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,580 main ERROR Unable to locate appender "rolling" for logger config "root"
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,580 main ERROR Unable to locate appender "index_indexing_slowlog_rolling" for logge
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,581 main ERROR Unable to locate appender "index_search_slowlog_rolling" for logger
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,581 main ERROR Unable to locate appender "deprecation_rolling" for logger config "o
Nov 20 16:32:29 bahar elasticsearch[8653]: [2016-11-20T16:32:25,592][WARN ][o.e.c.l.LogConfigurator ] ignoring unsupported logging configuration
Nov 20 16:32:30 bahar systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
Nov 20 16:32:30 bahar systemd[1]: elasticsearch.service: Unit entered failed state.
Nov 20 16:32:30 bahar systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
This is the error for the PATH and LOgs in the elasticsearch.yml (etc/elasticsearch/elasticsearch.yml)
Uncheck these path and your error will be removed.
That means elasticsearch is not running. And from what I see, there is a problem with starting it. Check your elasticsearch configuration.
check if Elasticsearch is running,run the follwing command:
$ ps aux|grep elasticsearch
if Elasticsearch is not started,check your JAVA Environment,download a new Elasticsearch and install it again:
1.check if JAVA is correctly installed:
$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
if your JAVA version is lower 1.7,change a new one.
2.download Elasticsearch install package,unzip it:
$ tar -zxvf elasticsearch-2.3.3.gz
3. run Elasticsearch
$ cd elasticsearch-2.3.3
$ ./bin/elasticsearch
Usually it's the write permission issue for the log directory (default as /var/log/elasticsearch), use ls -l to check the permission and change mode to 777 for the log directory and files if necessary.
Long story short: a system reboot might get it OK.
It has been a while since the question is asked. Anyway, I ran into a similar problem recently.
The elasticsearch service on one of my nodes died, with error saying similar to those posted in the question when restart the service. It says the log folder to write is read-only file system. But these files and directories are indeed owned by user elasticsearch (version 5.5, deployed on Cent OS 6.5), there should not be a read-only problem.
I checked and didn't find a clue. So, I just reboot the system. After rebooting, everything goes all right without any further tuning: elasticsearch service starts on boot as configured, it finds the cluster and all the other nodes, and the cluster health status turns green after a little while.
I guess, the root reason might be some hardware failure in my case. All data and logs managed by elasticsearch cluster are stored in a 2TB SSD driver mounted on each node. And our hardware team just managed to recover from an external storage failure recently. All the nodes restarted during that recovery. Chances are there are some lagged issues caused the problem.

Node.js stopped with "Sending SIGTERM to child" for no reason

This problem is pretty much the same issue posted on https://www.openshift.com/forums/openshift/nodejs-process-stopping-for-no-reason. Unfortunately it remains unanswered.
Today my Node.js app stopped few times with DEBUG: Sending SIGTERM to child... on the logfile. No more, no less. My application is a very simple single-page app with single AJAX endpoint, serving 1k-2k pageviews per day. It has been running well for days without any problem.
I use these modules:
express
body-parser
request
cheerio
-- Update:
I'm using one small gear. 512MB mem, 1 GB storage
Excerpts from log file (~/app-root/logs/nodejs.log)
Thu Jul 17 2014 09:12:52 GMT-0400 (EDT) <redacted app log message>
Thu Jul 17 2014 09:13:09 GMT-0400 (EDT) <redacted app log message>
Thu Jul 17 2014 09:14:33 GMT-0400 (EDT) <redacted app log message>
DEBUG: Sending SIGTERM to child...
#### below are the log entries after issuing "ctl_app restart"
DEBUG: Running node-supervisor with
DEBUG: program 'server.js'
DEBUG: --watch '/var/lib/openshift/redacted/app-root/data/.nodewatch'
DEBUG: --ignore 'undefined'
DEBUG: --extensions 'node|js|coffee'
DEBUG: --exec 'node'
DEBUG: Starting child process with 'node server.js'
Stats from oo-cgroup-read, as suggested by #niharvey. A bit too long, so I put it on http://pastebin.com/c31gCHGZ. Apparently I use too much memory: memory.failcnt 40583. I suppose Node.js is automatically (?) restarted on memory overusage events, but in this case it's not. I had to restart manually.
I forgot that I have an idle MySQL cartridge installed, now removed.
-- Update #2
The app crashed again just now. Value of memory.failcnt stays same (full stats on http://pastebin.com/LqbBVpV9), so it's not memory problem (?). But there are differences in the log file. The app seems restarted, but failed. After ctl_app restart it works as intented.
Thu Jul 17 2014 22:14:46 GMT-0400 (EDT) <redacted app log message>
Thu Jul 17 2014 22:15:03 GMT-0400 (EDT) <redacted app log message>
DEBUG: Sending SIGTERM to child...
==> app-root/logs/nodejs.log-20140714113010 <==
at Function.Module.runMain (module.js:497:10)
DEBUG: Program node server.js exited with code 8
DEBUG: Starting child process with 'node server.js'
module.js:340
throw err;
^
Error: Cannot find module 'body-parser'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
To simulate this problem on your local machine run your server with supervisor in one terminal window:
supervisor server.js
Then from another terminal use the kill command
kill process_id#
The kill command with no parameters sends a SIGTERM message to the application. If supervisor receives a SIGTERM it will stop immediately.
The sample code from the sample application provided by OpenShift listens to 12 different unix signals and exits. It could be that someone at OpenShift is manually killing the process because the application is not listening to a signal that was intended to reboot it. I'm adding this code to my application to see if the behavior is more stable.
function terminator(sig){
if (typeof sig === "string") {
console.log('%s: Received %s - terminating sample app ...',
Date(Date.now()), sig);
process.exit(1);
}
console.log('%s: Node server stopped.', Date(Date.now()) );
};
process.on('exit', function() { terminator(); });
['SIGHUP', 'SIGINT', 'SIGQUIT', 'SIGILL', 'SIGTRAP', 'SIGABRT',
'SIGBUS', 'SIGFPE', 'SIGUSR1', 'SIGSEGV', 'SIGUSR2', 'SIGTERM'
].forEach(function(element, index, array) {
process.on(element, function() { terminator(element); });
});
Usually this is because your app became idle. When you ssh into the app you should see something like:
*** This gear has been temporarily unidled. To keep it active, access
*** your app # http://abc.rhcloud.com/
You can try to use a scheduled ping to keep the app alive.
I had this same issue. I deleted the gear and created a new one. The new one has been running for a few days and doesn't seem to have the issue.
[Update]
After a few days, the issue appeared on my new gear.

Resources