We are using Monit to monitor mailman service, Worker nodes, and Opsworks agent.
It works fine till new we deploy new release.
On new release monit stops the Mailman Service and Start it.
And when I do SSH into server and check monit status it gives error "error connecting to the monit daemon"
How do I check the cause of monit daemon stops?
Related
I have created basic ASP.Net Core server on Azure Ubuntu VM. I have exposed the server to a port 80 using nginx.
I am conecting to the VM via ssh.
And starting the server with "dotnet run" command.
That works fine.
However, every time I close the ssh connection, the server is stopping as well.
Is there a way to start and keep running the asp.net core server on Linux without having an active ssh connection?
Basically what happens is:
You login with ssh
you startup an application under your user (dotnet run)
Close your ssh => logging out user, which means application is closed.
You need to start a service outside of your user. Here is some information:
https://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session
Otherwise i'd advice you to ask on https://askubuntu.com/
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.
I developed a nginx module to connect zookeeper, but I find the threads that created on zookeeper init were killed by nginx. When I debug by gdb with 'info threads', it only shows one thread, but it should be three threads. Why is this and how can I solve it?
I have deployed an "helloworld" service on cloudify 2.7 and OpenStack cloud. I would stop the service tomcat without the service is being restarted.
So, in the cloudify shell I have execute:
cloudify#default> connect cloudify-manager-1_IP
Connected successfully
cloudify#default> use-application helloworld
Using application helloworld
cloudify#helloworld> invoke tomcat cloudify:start-maintenance-mode 60
Invocation results:
1: OK from instance #1#tomcat_IP, Result: agent failure detection disabled successfully for a period of 60 minutes
invocation completed successfully
At this point, I have connected via ssh into the tomcat VM and ran:
CATALINA_HOME/bin/catalina.sh stop
In the CATALINA_HOME/log/catalina.out I can see that the app server is being stopped and immediately restarted!
So, what should I do in order to stop the app server and restart it only when I decide to restart it?
Maintenance mode in Cloudify 2.7 is used to prevent the system from starting a new VM if a service VM has failed.
What you are looking for is to prevent Cloudify from auto-healing a process - Cloudify checks for the liveness of the configured process, and if it dies, it executes the 'start' lifecycle again.
In your case, the monitored process can change, since you will be restarting it manually. So you should not use the default process monitoring. There is a similar question here: cloudify 2.7 locator NO_PROCESS_LOCATORS
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.