Our FTP service from our server just stops working and we have no idea why each time
we get this error: Status: Connection attempt failed with "ECONNREFUSED - Connection refused by server". Error: Could not connect to server
any ideas where to check in server?
If you are sure that the server is actually running. Try to restart it using something like:
service vsftpd restart
You need to replace vsftpd with whatever FTP you might be using. See if you get any erros when doing this.
Related
I'm newbie to clickhouse, I'm trying to create a clickhouse database on my unbuntu 18.04 remote server, I follow instruction to install click house from DEB package in this link: https://clickhouse.tech/docs/en/getting_started/install/#from-sources
after that when I run command clickhouse-client it shows something like this :
root#busmap-api-test:~# clickhouse-client
ClickHouse client version 20.3.5.21 (official build)
Connecting to localhost:9000 as user default.
Code: 209. DB::NetException: Timeout exceeded while reading from socket (127.0.0.1:9000)
Can someone help me to figure out what is the problem and how I can solve it?
Thanks,
Follow these steps to resolve the issue:
check that clickhouse-server-service started
service clickhouse-server status
check the server logs to find the possible reason
cat /var/log/clickhouse-server/clickhouse-server.err.log
if occured the error 'Address already in use':
{} <Error> Application: Net Exception: Address already in use: [::1]:9000
{} <Error> Application: Net Exception: Address already in use: 127.0.0.1:9000
need to switch CH-server to any other port by editing tcp_port-param in /etc/clickhouse-server/config.xml-file:
..
<tcp_port>9032</tcp_port>
..
restart CH-server service:
service clickhouse-server restart
and connect this way
clickhouse-client --port 9032
I actually had this problem too but I got it working with the default port.
The setting should be this way if you want to connect remotely and be able to use the loopback from localhost.
<listen_host>::1</listen_host>
<listen_host>0.0.0.0</listen_host>
This allows the loopback method to work (i.e clickhouse-client no args) on localhost to connect through the IPV6 route, and the remote connection (i.e clickhouse-client -h <hostname>) through the IPV4 connection.
My original problem was that i only used <listen_host>0.0.0.0</listen_host> in my config which meant theclickhouse-client no args would not work on localhost. And I could not get both to work by adding <listen_host>127.0.0.1</listen_host>
Use command "mount_smbfs //username:password#server/Shared /Volumes" to connect with Windows Server, but it return with "mount_smbfs: server connection failed: No such file or directory"
>>mount_smbfs //username:password#server/Shared /Volumes
mount_smbfs: server connection failed: No such file or directory
I can not use "Finder->Go->Connect to Server" neither. Each server I connect to as "smb://server" would return an error "There was a problem connecting to the server".
Beside, I could ping the server successfully.
The real problem is that SMB didn't work in My Mac, and someone give a workaround to fix it.
You can visit it
I was hoping someone could help.
I am trying to sftp to a remote server that is behind a firewall. I have a proxy setup and can sftp via the unix terminal succesfully. However when using mulesofts SFTP connector I get a timeout. From research it looks like this is because it is run on the JVM.
Mule comes with wrapper.conf to update any jvm settings so I have set the following settings:
wrapper.java.additional.15=-DsocksProxyHost:hostname
wrapper.java.additional.16=-DsocksProxyPort=1080
When I do this the Mule service no longer runs and get the following error:
WrapperManager Error: Unexpected exception opening backend socket: java.net.SocketException: Can't connect to SOCKS proxy:Invalid argument or cannot assign requested address
Hopefully someone can assist.
Thank you.
Perhaps typo in the
-DsocksProxyHost:hostname
Should be = rather than :.
The port is unnecessary, 1080 is the default. Documentation is here, see section 2.4 for SOCKS
http://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html
I have been trying to setup aws ec2 machines for load testing of my web server using jmeter but I am stuck. I have a jmeter client on my local machine and I want to set up multiple jmeter-server nodes on ec2 to do the load testing and I am, thus far, just trying to get one server node up and running. But it hasn't worked out for me yet.
I have the same jmeter running on my local machine and the server and the java version was a little different but I don't think that is the problem. Most of the people have had problems with getting the correct ip for connecting between the client and the server nodes but I, after a lot of searching, have gotten through all those problems. I am stuck at when the server node attempts to return the result and tries to connect to the client, my local machine. The server tries to connect to the external ip address of my local machine. But it throws a connection refused error, which apparently was caused by connection timeout. I guess it's some firewall issue but I tried turning off the firewall on my local machine but it still throws the same error. I am not sure how can I get past this and it's taking way too much time then it should.
Could somebody please suggest me something to solve this? Thanks!
My local machine is a Mac OS X 10.7.5 and my server nodes are on ubuntu.
This is the error that it throws:
2013/01/29 12:23:37 ERROR - jmeter.samplers.RemoteListenerWrapper: testStarted(host) java.rmi.ConnectException: Connection refused to host: xxx.xxx.xxx.10; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:128)
at org.apache.jmeter.samplers.RemoteSampleListenerImpl_Stub.testStarted(Unknown Source)
at org.apache.jmeter.samplers.RemoteListenerWrapper.testStarted(RemoteListenerWrapper.java:83)
at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:226)
at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:349)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
at java.net.Socket.connect(Socket.java:546)
at java.net.Socket.connect(Socket.java:495)
at java.net.Socket.<init>(Socket.java:392)
at java.net.Socket.<init>(Socket.java:206)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
... 8 more
Well, I finally solved the problem. I ended up using ssh reverse tunnels. I am not sure if there is a better way to do this though. So, in case anyone has a similar problem, this is how I did it:
Create a reverse ssh tunnel from the server to the client. So, at client side:
ssh -Nf -R [client.rmi.localport]:localhost:[client.rmi.localport on serverside] user#server
start server and have a client.rmi.localport as well; the port at which the tunnel was created;
start the client as: ./bin/jmeter-server -Djava.rmi.server.hostname=127.0.0.1.
And that's it! You have your distributed testing ready.
Solution that worked for me on Linux/OSX:
1.On the client edit bin/jmeter.properties and add:
remote_hosts=127.0.0.1:55501
client.rmi.localport=55512
mode=Batch
num_sample_threshold=250
2.On the server edit bin/jmeter.properties and add:
server_port=55501
server.rmi.localhostname=127.0.0.1
server.rmi.localport=55511
3.Now connect to the server using this ssh tunel:
ssh -L 55501:127.0.0.1:55501 -L 55511:127.0.0.1:55511 -R 55512:127.0.0.1:55512 user#hostname
4.Edit jmeter-server script to start jmeter.sh
${DIRNAME}/jmeter.sh ${RMI_HOST_DEF} -Dserver_port=${SERVER_PORT:-1099} -s -j jmeter-server.log "$#"
5.Now run on the server:
bin/jmeter-server -Djava.rmi.server.hostname=127.0.0.1
6.And on the client run jmeter with gui or add -n if gui is not needed:
bin/jmeter.sh -Djava.rmi.server.hostname=127.0.0.1
or, with test plan:
bin/jmeter.sh -Djava.rmi.server.hostname=127.0.0.1 -t /path/to/test-plan.jmx
Looks like you have to move your jmeter-master instance (jmeter client) to EC2 instance too.
As per JMeter Distributed Testing Step-by-step:
2. check all the clients are on the same subnet;
For distributed testing to work, the systems must be on the same subnet, otherwise RMI will not be able to connect.
Looks like to be your case: jmeter-slaves are in one subnet (EC2) and jmeter-master in another (your local workstation).
I wrote a free, open source script to help do exactly this. I went through the same issues listed by the OP and, even though I did get things working in the end, it was never great and I wanted something to automate away the hassle.
I need to connect DbVisualizer to HSQLDB. I've installed both on my mac (OSX 10.6.9). I've installed DbVisualized 8.0.5, and HSQLDB. I have both open, but when I try to ping the server, I receive the error message: "Cannot connect to 'localhost' on port 9001." The message below shows up in the Connection Message window:
An error occurred while establishing the connection:
Long Message:
java.net.ConnectException: Connection refused
Details:
Type: java.sql.SQLTransientConnectionException
Error Code: -1301
SQL State: 08001
By default, when you run the HSQLDB Server, it shows some messages in the window. The last maessage should indicate susseful startup.
[Server#80fa6f]: 2011-11-12 21:03:24.904 HSQLDB server 2.2.6 is online on port 9001
[Server#80fa6f]: To close normally, connect and execute SHUTDOWN SQL
When you ping from DbVis, the server rejects the data because it's not valid data for making a connection. It shows an exception. This is normal behaviour. On the DBVis side, it should return success after the ping.
You should then connect from DbVis and it should work.
You must use the same HSQLDB jar on both DbVis and HSQLDB (you probably have done this).
You can also double check by executing the HSQLDB (version 2.2.x) jar, which brings up its own database manager and allows you to connect to the server.
One likely cause is network problems. You can try the IP address 127.0.0.1 instead of 'localhost'