When I running a fluentd td-agent to read the data from the tcp port 514 using tcp plugin but I find the error as,
2015-05-25 15:32:18 +0000 [info]: adding match pattern="tcp.events" type="stdout"
2015-05-25 15:32:18 +0000 [info]: adding source type="tcp"
2015-05-25 15:32:18 +0000 [error]: unexpected error error_class=Errno::EACCES error=#<Errno::EACCES: Permission denied - bind(2) for "0.0.0.0" port 514>
When I try to read the data from TCP port I find the data as
nc -l 514
<30>May 25 21:15:11 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:11 UTC 2015
<30>May 25 21:15:12 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:12 UTC 2015
<30>May 25 21:15:13 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:13 UTC 2015
<30>May 25 21:15:14 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:14 UTC 2015
<30>May 25 21:15:15 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:15 UTC 2015
Thanks in advance
Any port number under 1024 requires root permission. It's called privileged ports. Could you try with bigger port number?
Related
I've setup an Ubuntu 16.04 EC2 t2.medium server and followed the instructions here http://docs.bigbluebutton.org/2.0/20install.html to install BigBlueButton 2.0-beta.
When I log into the Demo Meeting room and select Microphone it says calling... then changes to connecting... and then I get a message saying:
WebRTC Audio Failure
Detected the following WebRTC issue: Error 1010: ICE negotiation
timeout. Do you want to try Flash instead?
Here is the output from the console:
BigBlueButton call accepted
bbb_webrtc_bridge_sip.js?v=591:497 Waiting for ICE negotiation
sip.js?v=591:2900 Thu Sep 21 2017 11:27:19 GMT+0800 (WITA) | sip.invitecontext.mediahandler | stream added: fuEOgOt7p5aHrW58wGtGVszgTdGBcNKi
sip.js?v=591:2900 Thu Sep 21 2017 11:27:24 GMT+0800 (WITA) | sip.invitecontext.mediahandler | RTCIceChecking Timeout Triggered after 5000 milliseconds
bbb_webrtc_bridge_sip.js?v=591:499 5 seconds without ICE finishing
bbb_webrtc_bridge_sip.js?v=591:119 Stopping webrtc audio test
bbb_webrtc_bridge_sip.js?v=591:555 Hanging up current session
sip.js?v=591:2900 Thu Sep 21 2017 11:27:24 GMT+0800 (WITA) | sip.inviteclientcontext | terminating Session
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | sending WebSocket message:
BYE sip:919673089#172.31.36.135:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS msk2aa46iuih.invalid;branch=z9hG4bK7275105
Max-Forwards: 70
To: <sip:919673089#staging.bigbluebutton.xxxxxx.com>;tag=SBBF64e6999Hm
From: "w_zqmgpmdukz39-bbbID-Mikhail" <sip:w_zqmgpmdukz39-bbbID-Mikhail#staging.bigbluebutton.xxxxxx.com>;tag=d6e9kj05rj
Call-ID: epjgsffnq2hi688jlvgl
CSeq: 9777 BYE
Supported: outbound
User-Agent: BigBlueButton
Content-Length: 0
bbb_webrtc_bridge_sip.js?v=591:465 call ended null
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.inviteclientcontext | closing INVITE session epjgsffnq2hi688jlvglj9cdnvthcr
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.invitecontext.mediahandler | closing PeerConnection
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.dialog | dialog epjgsffnq2hi688jlvgld6e9kj05rjSBBF64e6999Hm deleted
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.ua | user requested closure...
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.ua | closing registerContext
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.registercontext | already unregistered
LoggerFactory.print # sip.js?v=591:2900
LoggerFactory.(anonymous function) # sip.js?v=591:2917
Logger.(anonymous function) # sip.js?v=591:2911
unregister # sip.js?v=591:3579
close # sip.js?v=591:3570
UA.stop # sip.js?v=591:8929
(anonymous) # bbb_webrtc_bridge_sip.js?v=591:505
setTimeout (async)
(anonymous) # bbb_webrtc_bridge_sip.js?v=591:498
EventEmitter.emit # sip.js?v=591:115
accepted # sip.js?v=591:5641
onSuccess # sip.js?v=591:6851
Promise resolved (async)
receiveInviteResponse # sip.js?v=591:6832
receiveResponse # sip.js?v=591:3784
InviteClientTransaction.receiveResponse # sip.js?v=591:7832
onMessage # sip.js?v=591:8566
ws.onmessage # sip.js?v=591:8424
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | received WebSocket text message:
SIP/2.0 200 OK
Via: SIP/2.0/WSS msk2aa46iuih.invalid;branch=z9hG4bK7275105;received=52.51.xx.xx;rport=38902
From: "w_zqmgpmdukz39-bbbID-Mikhail" <sip:w_zqmgpmdukz39-bbbID-Mikhail#staging.bigbluebutton.xxxxxx.com>;tag=d6e9kj05rj
To: <sip:919673089#staging.bigbluebutton.xxxxxx.com>;tag=SBBF64e6999Hm
Call-ID: epjgsffnq2hi688jlvgl
CSeq: 9777 BYE
User-Agent: FreeSWITCH-mod_sofia/1.9.0+git~20170822T213300Z~2ebdf42f2c~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Content-Length: 0
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | closing WebSocket wss://staging.bigbluebutton.xxxxxx.com/ws
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | WebSocket disconnected (code: 1000)
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.ua | connection state set to 1
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transaction.ict | transport error occurred, deleting INVITE client transaction z9hG4bK9694442
I've searched for anything related to bigbluebutton error 1010 but can't find anything.
Please check your firewall :
TCP ports 80, 443,and 1935 are accessible.
TCP port 7443 is accessible if you intend to configure SSL (recommended), otherwise port 5066 is accessible.
UDP ports 16384 - 32768 are accessible.
Port 80 is not in use by another application.
the problem is your sip ip and port.
Check /opt/freeswitch/etc/freeswitch/sip_profiles/external.xml settings firstly.
ws-binding: :5066
wss-binding: :7443
change it to like this:
ws-binding: your_external_ip_address:5066
wss-binding: your_external_ip_address:7443
Your external ip address is same with external_sip_ip address.
Then check your 5066 and 7443 port if you use firewall.
Then dont forget to restart bbb (bbb-conf --restart)
I use an apache storm topology on a cluster of 8+1 machines. The date on these machines is not the same and we may have more than 5 minutes of difference.
preprod-storm-nimbus-01:
Thu Feb 25 16:20:30 GMT 2016
preprod-storm-supervisor-01:
Thu Feb 25 16:20:32 GMT 2016
preprod-storm-supervisor-02:
Thu Feb 25 16:20:32 GMT 2016
preprod-storm-supervisor-03:
Thu Feb 25 16:14:54 UTC 2016 <<-- this machine is very late :(
preprod-storm-supervisor-04:
Thu Feb 25 16:20:31 GMT 2016
preprod-storm-supervisor-05:
Thu Feb 25 16:20:17 GMT 2016
preprod-storm-supervisor-06:
Thu Feb 25 16:20:00 GMT 2016
preprod-storm-supervisor-07:
Thu Feb 25 16:20:31 GMT 2016
preprod-storm-supervisor-08:
Thu Feb 25 16:19:55 GMT 2016
preprod-storm-supervisor-09:
Thu Feb 25 16:20:30 GMT 2016
Question:
Is the storm topology affected by this non-synchronization?
Note: I know that synchronizing is better, but the sysadmins won't do it without proving them proofs/reasons that they have to do it. Do they really have to do it, "for the topology's sake" :) ?
Thanks
It depends on the computation you are doing... It might have an effect on your result if you do time based window operations. Otherwise, it doesn't matter.
For Storm as an execution engine it has no effect at all.
I am using elasticdump to dump data from local machine to the server. But my dumps always ended with this error:
...
Tue, 20 Oct 2015 22:56:35 GMT | sent 100 objects to destination elasticsearch, wrote 100
Tue, 20 Oct 2015 22:56:35 GMT | got 100 objects from source elasticsearch (offset: 21200)
Tue, 20 Oct 2015 22:56:36 GMT | Error Emitted => read ECONNRESET
Tue, 20 Oct 2015 22:56:36 GMT | Total Writes: 21200
Tue, 20 Oct 2015 22:56:36 GMT | dump ended with error (set phase) => Error: read ECONNRESET
...
How should I solve this problem?
Is there a better way to dump data from local machine to the server? Thanks in advance!
It sounds like your issue is being caused by the elasticdump opening too many sockets to your elasticsearch cluster. You can use the --maxSockets option to limit the number of sockets opened.
For example:
$ elasticdump --input http://192.168.2.222:9200/index1 --output http://192.168.2.222:9200/index2 --type=data --maxSockets=5
You can find a detailed explanation of the issue here:
https://github.com/taskrabbit/elasticsearch-dump/issues/98
Jmeter is taking always the same time to finish remote test. The jmx script is simple and there is no time configured on it, and there are just one request (only 84ms in local test).
It happens only on remote test, in local test is ok.
Starting the test on host x.x.x.x # Thu Aug 14 09:31:43 BRT 2014 (1408019503091)
Finished the test on host x.x.x.x # Thu Aug 14 09:34:43 BRT 2014 (1408019683082)
Starting the test on host x.x.x.x # Thu Aug 14 09:35:53 BRT 2014 (1408019753107)
Finished the test on host x.x.x.x # Thu Aug 14 09:38:53 BRT 2014 (1408019933091)
Starting the test on host x.x.x.x # Thu Aug 14 09:40:33 BRT 2014 (1408020033110)
Finished the test on host x.x.x.x # Thu Aug 14 09:43:33 BRT 2014 (1408020213100)
Starting the test on host x.x.x.x # Thu Aug 14 10:03:23 BRT 2014 (1408021403158)
Finished the test on host x.x.x.x # Thu Aug 14 10:06:23 BRT 2014 (1408021583154)
Starting the test on host x.x.x.x # Thu Aug 14 10:07:53 BRT 2014 (1408021673181)
Finished the test on host x.x.x.x # Thu Aug 14 10:10:53 BRT 2014 (1408021853164)
Starting the test on host x.x.x.x # Thu Aug 14 10:25:23 BRT 2014 (1408022723204)
Finished the test on host x.x.x.x # Thu Aug 14 10:28:23 BRT 2014 (1408022903204)
Starting the test on host x.x.x.x # Thu Aug 14 10:33:13 BRT 2014 (1408023193224)
Finished the test on host x.x.x.x # Thu Aug 14 10:36:53 BRT 2014 (1408023413225)
Just reinstalled Mongodb on my mac (fresh install of mountain lion 10.8) and now my apps are taking ~3 mins to connect.
I put together a simple node script to test this:
var start = (new Date()).getTime();
var mongoose = require('mongoose');
var db = mongoose.connect('mongodb://localhost/passport-mongox',function(err){
var stop = (new Date()).getTime();
console.log('Took this long: ',(stop-start) / 1000 );
});
Both times were 175.273 and 175.316 seconds.
When I connect to an external, hosted mongodb it connects in less than a second,
Any idea why this would happen? Here is my mongo.log:
Fri Feb 1 12:43:25 [initandlisten] MongoDB starting : pid=2262 port=27017 dbpath=/usr/local/var/mongodb 64-bit host=w
Fri Feb 1 12:43:25 [initandlisten] db version v2.2.2, pdfile version 4.5
Fri Feb 1 12:43:25 [initandlisten] git version: d1b43b61a5308c4ad0679d34b262c5af9d664267
Fri Feb 1 12:43:25 [initandlisten] build info: Darwin bs-osx-106-x86-64-1.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 BOOST_LIB_VERSION=1_49
Fri Feb 1 12:43:25 [initandlisten] options: { bind_ip: "127.0.0.1", config: "/usr/local/etc/mongod.conf", dbpath: "/usr/local/var/mongodb", logappend: "true", logpath: "/usr/local/var/log/mongodb/mongo.log" }
Fri Feb 1 12:43:25 [initandlisten] journal dir=/usr/local/var/mongodb/journal
Fri Feb 1 12:43:25 [initandlisten] recover : no journal files present, no recovery needed
Fri Feb 1 12:43:26 [websvr] admin web console waiting for connections on port 28017
Fri Feb 1 12:43:26 [initandlisten] waiting for connections on port 27017
Fri Feb 1 12:44:05 [initandlisten] connection accepted from 127.0.0.1:52137 #1 (1 connection now open)
Fri Feb 1 12:44:40 [initandlisten] connection accepted from 127.0.0.1:52152 #2 (2 connections now open)
Fri Feb 1 12:45:15 [initandlisten] connection accepted from 127.0.0.1:52201 #3 (3 connections now open)
Fri Feb 1 12:45:50 [initandlisten] connection accepted from 127.0.0.1:52298 #4 (4 connections now open)
Fri Feb 1 12:46:25 [initandlisten] connection accepted from 127.0.0.1:52325 #5 (5 connections now open)
Fri Feb 1 12:51:26 [conn5] end connection 127.0.0.1:52325 (4 connections now open)
Fri Feb 1 12:51:26 [conn3] end connection 127.0.0.1:52201 (4 connections now open)
Fri Feb 1 12:51:26 [conn4] end connection 127.0.0.1:52298 (4 connections now open)
Fri Feb 1 12:51:26 [conn1] end connection 127.0.0.1:52137 (4 connections now open)
Fri Feb 1 12:51:26 [conn2] end connection 127.0.0.1:52152 (4 connections now open)
Answer from mongoose.js
Cause:
The underlying MongoDB driver defaults to looking for IPv6 addresses,
so the most likely cause is that your localhost DNS mapping isn't configured to handle IPv6.
Solution :
Use 127.0.0.1 instead of localhost or use the family option as shown in the connection docs.
mongoose.connect(url, {family:4}, function(err, connection) {
connection.db(your_db_name);
});
So the answer came from #AdamMeghji on twitter.
My hosts file has always looked like this:
127.0.0.1 localhost
127.0.0.1 test.com
127.0.0.1 wes.dev
I switched that to:
127.0.0.1 localhost test.com wes.dev
and connections went back to 0.015 seconds.