I am using paramiko as ssh client for remote machine and starting a new tmux session using the client. After sometime I am getting a broken pipe exception. Socket exception: Connection reset by peer (54). Because of this my tmux sessions are killed. I tried changing ssh.socket to service and also added Killmode in ssh#.service. But still i am getting the same exception. Any suggestions to solve this error?
Related
I'm asking you a question because I need your help.
I have built a redis server in a docker container and am using it in cluster mode.
I can access the redis server and ping well.
However, when executing the get/set command, the following error message is output and the connection with the redis is lost.
Could not connect to Redis at 172.19.0.4:6300: Connection failed due to no response from the connected member or connection was lost due to no response from the host.
I would really appreciate it if you could help me with the above problem.
I guessed that the connection and ping were done well, so it was a security-related configuration problem.
So I tried to set the security setting of the redis.conf file to no, but the problem was not solved.
'protected-mode no'
we operate CENM(1.2 and use helm template to run on k8s cluster) to construct our own private network and keep on running CENM network map server for a few week, then launching new node start failing.
with further investigation, its appeared that request timeout for http://nmap:10000/network-map causes problem.
in nmap server’s log, we found following output when access to above url with curl.
[NMServer] - Error while handling socket client message com.r3.enm.servicesapi.networkmap.handlers.LatestUnsignedNetworkParametersRetrievalMessage#760c53ea: HikariPool-1 - Connection is not available, request timed out after 30000ms.
netstat shows there is at least 3 establish connection to the database from the container which network map server runs, also I can connect database directly with using CLI.
so I don’t think it is neither database saturated nor network configuration problem.
anyone have an idea why this happens? I think restart probably solve the problem, but want to know the root cause...
regards,
Please test the following options.
Since it is the HikariCP (connection pool) component that is throwing the error it would be worth seeing if increasing the pool size in the network map configuration may help - see below)
Corda uses Hikari Pool for creating the connection pool. To configure the connection pool any custom properties can be set in the dataSourceProperties section.
dataSourceProperties = {
dataSourceClassName = "org.postgresql.ds.PGSimpleDataSource"
...
maximumPoolSize = 10
connectionTimeout = 50000
}
Has a healthcheck been conducted to verify there are sufficient resources on that postgres database i.e basic diagnostic checks ?
Another option to get more information logged from the network map service is to run with TRACE logging also:
From https://docs.corda.net/docs/cenm/1.2/troubleshooting-common-issues.html
Enabling debug/trace logging
Each service can be configured to run with a deeper log level via command line flags passed at startup:
java -DdefaultLogLevel=TRACE -DconsoleLogLevel=TRACE -jar <enm-service-jar>.jar --config-fi
I got a problem with ssh connection.
I executed commands on a remote Linux server via python paramiko. The command executed for a long time(more than 40 minutes) and then returned the message which I want to check, there was no message returned during the executing.
I have tried different ways:
The ssh connection fails before the result returns if I don't change the sshd config on the remote server.
Enabled TCPKeepAlive/ClientAliveInterval/ClientAliveCountMax on the remote server, the server sent messages to the client during the idle period cyclically, the message was unhandled keepalive request...... It prevents the connection from timing out, but in this way, I can't get the message returned by the command.
Help me, thank you!
I'm trying to write a go application that would allow me to perform reverse ssh tunneling between a Windows machine and a Linux machine using the go ssh library.
In the process of doing so, I create a listener on the remote machine, as follows:
remoteListener, err := sshClient.Listen("tcp", remoteString)
where sshClient is an object of type ssh.Client and is configured to connect to the remote machine.
The issue here is that when the sshd process on the Linux machine disrupts the connection with the application, the ssh Listener remains alive on the remote machine. So, reconnecting with the application fails because a listener is already running on the same port on the remote machine.
How do I get around this issue? Does the ssh library allow me to define a timeout on the listener?
I'm just waiting for the timeout after reconnecting. I found no other easy solution for this.
No way to have console wired with Heroku lately:
lsoave#ubuntu:~/rails/github/gitwatcher$ heroku run console
Running console attached to terminal...
Timeout awaiting process
lsoave#ubuntu:~/rails/github/gitwatcher$
Does it happen to anyone else ?
I had the same problem on the ISP FastWeb, which is an ISP here in Italy. Based on my Googling, it appears that they block port 5000.
To get around it for now, I am running the following:
heroku run:detached rake db:migrate
That tells it to run without waiting to connect to my machine on port 5000.
Then, you can examine the logs for your process you just kicked off. (The heroku command will tell you this after you run it):
heroku logs -p run.1
That tells it to output the logs for the running process.
But I found that the logs command was exiting even though my process was still running.
To get around that, you can add "-t" if you want to "tail" the logs:
heroku logs -p run.1 -t
You'll know your process is done when you see something like this in the logs:
2012-10-14T15:36:41+00:00 heroku[run.1]: Process exited with status 0
2012-10-14T15:36:41+00:00 heroku[run.1]: State changed from up to complete
I'm sure someone could whip up a script that would
Run the given heroku command with run:detached
Examine the output to determine what its process name was (run.1, run.2, etc)
run heroku logs -p run.1 -t and show me the output
exit the logs process when it sees something like State changed from up to complete
From: http://devcenter.heroku.com/articles/oneoff-admin-ps
The heroku run process opens a connection to Heroku on port 5000. If
your local network or ISP is blocking port 5000, or you are
experiencing a connectivity issue, you will see an error similar to:
$ heroku run rails console
Running rails console attached to terminal...
Timeout awaiting process
You can test your connection to Heroku by trying to connect directly
to port 5000 by using telnet to rendezvous.heroku.com. A successful
session will look like this:
$ telnet rendezvous.heroku.com 5000
Trying 50.19.103.36...
Connected to ec2-50-19-103-36.compute-1.amazonaws.com.
Escape character is '^]'.
If you do not get this output, your computer is being blocked from
accessing our services. We recommend contacting your IT department,
ISP, or firewall manufacturer to move forward with this issue.
There's a way to bypass this restriction by executing commands you were going to execute with 'heroku run ...' directly as system calls.
For this heroku command:
heroku run rake db:migrate
One could make a call in Ruby
system("rake db:migrate")
This call could be done as a result on some HTTP GET request - you better protect by some means, so that it wouldn't be accessible for strangers.
It's not a nice way - but when you don't have a choice - it works.
I had the same problem on the ISP FastWeb, which is an ISP here in Italy.
The most simple way to overcome the problem is set a VPN when you are using heroku run (something)
Personally I use Tunnel Bear that offer you 0.5GB of internet traffic for free
I've just connected successfully to a console on Heroku
Is it all apps or just a single one? I'd suggest checking your heroku gem is up to date, that you can run other commands like heroku ps, restart your application via heroku restart - if you've tried these then get in touch with Heroku support as something is wrong with your application.