I m trying to run monit in my ubuntu system . I followed the complete steps the was giving in link . ie (https://www.tecmint.com/how-to-install-and-setup-monit-linux-process-and-services-monitoring-program/)
every thing is fine i m not getting any error but still when i try to load it on browser (This site can’t be reached localhost refused to connect) is showing on browser i m not getting any solution.
[un-commented code][1]
set httpd port 2812 and
use address 10.0.4.115 # only accept connection from localhost
allow 10.0.4.115 # allow localhost to connect to the server and
allow admin:monit # require user 'admin' with password 'monit'
allow #monit
allow #users readonly
kundan#CHEALPHADT005:~$ sudo monit status
Monit 5.25.1 uptime: 2h 35m
System 'CHEALPHADT005'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
load average [0.43] [0.45] [0.22]
cpu 0.7%us 0.4%sy 0.5%wa
memory usage 2.3 GB [29.6%]
swap usage 0 B [0.0%]
uptime 2h 35m
boot time Fri, 15 Feb 2019 12:21:56
data collected Fri, 15 Feb 2019 14:57:15
It appears you edited out 127.0.0.1 and replaced it with 10.0.4.115 in two places.
Read the comments next to the first 3 lines you posted above.
I recommend you remove the 'use address' line and make multiple allow lines.
set httpd port 2812
allow localhost
allow 10.0.3.115
Related
My apache services are working on solaris server. It will be running normally for days but suddenly it hangs. httpd will shown process running but telnet localhost will not connect.
telnet localhost will only connect if you are running a local telnet server...I believe Sun started turning that off by default in Solaris 10.
telnet localhost 80 will try to connect to port 80, where your Apache server might be running. But many Apache configurations are not set to listen on localhost. Instead, try telnet XXX 80, where XXX is the IP number that Apache is listening on. You can see a list of the IP addresses on your current zone with ifconfig -a.
If Apache really IS hanging, you are going to need to gather more information, like
what happens when you telnet into it
what is the output of netstat -an | grep LISTEN | grep '\*\.80'
does it start working again when you HUP the main process (look for the pid which is the parent of all the others)
what is in the main Apache error_log?
Apache is extremely stable, and if it's hanging, you likely have a either an astable plugin, or somehow you are consuming too many of some resource (like you have a 1000-child limit and 1000 people doing http long poll or something)
I've been connecting to a Google Cloud VM instance via gcloud ssh from my macOS:
$ gcloud compute ssh [username]#[instance]
Starting from a week ago, the connection will just drop after ~60 seconds of idle connection and returns:
Connection to [my_external_ip] closed by remote host.
Connection to [my_external_ip] closed.
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
I configured the TCP keepalive time to 30 seconds on both my macbook and the VM. But that did not solve the problem.
Any idea how do I extend the connection duration?
This is unlikely an issue with your timeout setting, but more likely an issue with your firewall rules or routes.
Firstly I would suggest checking your firewall rules and ensure you have an ingress firewall rule opening port 22. If you have, check the configuration of this rule, in particular:
Check the IP range in 'Source filters'. Does the range include the IP address of your home computer? For testing purposes, to ensure it does, you could temporarily set this to 0.0.0.0/0 to include all IP addresses.
Check the 'Targets' drop-down. Is this set to apply to 'All instances in the network' or is it set to 'Specified target tags'? If you have set it to 'Specified target tags', make sure that the same tag is added to the 'Network tags' section of the instance, otherwise the firewall rule will not apply to the instance and allow SSH traffic.
Ensure this rule has a higher priority than any other rules that could counteract it (when I say higher priority I mean lower number, for example, a a rule with a priority of 1000 is a higher priority than a rule with a priority of 20000).
If the above doesn't resolve the issue, run the following command to check the routes:
gcloud compute routes list
Ensure there is an entry which contains the following:
default 0.0.0.0/0 default-internet-gateway
EDIT
If you are able to sometimes SSH into the instance but then the connection drops, there may be some useful information in the logs, or the serial console.
You can access the serial console by clicking on the instance name in the GCP Console, then clicking on "Serial port 1 ".
When you SSH into the instance, information about the SSH session populates the serial console output (this can be refreshed by hitting the 'Refresh' at the top of the page.) Information about the session ending also populates the serial console. There may be some useful information/clues about why the session ends in this output.
It might also be worth checking the status of SSH daemon on the instance and giving it a restart to see if that makes a difference:
Check status of sshd:
systemctl status sshd
Restart sshd:
sudo systemctl restart sshd
I am setting up an ambari cluster with 3 virtualbox VMs running Ubuntu 16.04LTS.
I followed this hortonworks tutorial.
However when I am going to create a cluster using Ambari Cluster Install Wizard I get the below error during the step 3 - "Confirm Hosts".
26 Jun 2017 16:41:11,553 WARN [Thread-34] BSRunner:292 - Bootstrap process timed out. It will be destroyed.
26 Jun 2017 16:41:11,554 INFO [Thread-34] BSRunner:309 - Script log Mesg
INFO:root:BootStrapping hosts ['thanuja.ambari-agent1.com', 'thanuja.ambari-agent2.com'] using /usr/lib/python2.6/site-packages/ambari_server cluster primary OS: ubuntu16 with user 'thanuja'with ssh Port '22' sshKey File /var/run/ambari-server/bootstrap/5/sshKey password File null using tmp dir /var/run/ambari-server/bootstrap/5 ambari: thanuja.ambari-server.com; server_port: 8080; ambari version: 2.5.0.3; user_run_as: root
INFO:root:Executing parallel bootstrap
Bootstrap process timed out. It was destroyed.
I have read number of posts saying that this is related to not enabling Password-less SSH to the hosts. But I can ssh to the hosts without password from the server.
I am running ambari as non-root user with root privileges.
This post helped me.
I modified the users in host machines so that they can execute sudo commands without password using visudo command.
Please post if you have any alternative answers.
Inside the perl script I'm running the below
my #lines = `ps -ef`;
And currently, when I output the array into my browser I can only see the following processes:
UID PID PPID C STIME TTY TIME CMD
root 1928 1 0 Feb18 ? 00:00:00 /usr/sbin/abrtd
apache 9198 9121 1 17:23 ? 00:00:00 /usr/bin/perl /var/www/cgi-bin/tbchecker.pl
apache 9199 9198 0 17:23 ? 00:00:00 ps -ef
I think the issue is that the apache user needs to have access to see all the processes running on the server, but am not sure.
Could anyone help point me in the right direction?
(OS is Linux centos 6.4)
Your assumption that the apache user "needs to have access to see all the processes running on the server" is false (on a well-configured Apache2 server).
It is recommended to run the apache httpd server processes under a special account with restricted priviledges.
If you really want to change this and you know the implications of it, you can configure Apche2 to run under the root account. The Apache documentation on http://httpd.apache.org/docs/2.4/ is your friend.
There is still the possibility to run the perl script as user root with the SUID bit set. Note that I have not tested whether it will give you the desired output; normal shell scripts can't be run in SUID mode (under Linux, at least) and the shell drops the additional priviledges before executing a command.
The solution was to replace this line:
check process apache with pidfile /var/run/httpd.pid
With this line:
check process httpd with pidfile /var/run/httpd/httpd.pid
And I also removed the 'group apache'.
Original post:
After installing Monit on CentOS, and setting an alert for the Apache (httpd) service, the service no longer creates the /var/run/httpd.pid file.
The httpd service IS running properly.
On top of it, as if that's not enough, Monit reports the status of the service as: Execution failed
Naturally, the only way to restart such a service is by killing it, since the 'restart' script doesn't see any running process.
These are the contents of the /etc/monit.d/monitrc file:
set daemon 10
set logfile syslog facility log_daemon
set mailserver localhost
set mail-format { from: me#server.com }
set alert bugs#server.com
set httpd port 2812 and
# SSL ENABLE
# PEMFILE /var/certs/monit.pem
allow user:password
check process apache with pidfile /var/run/httpd.pid
group apache
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if cpu is greater than 180% for 1 cycles then alert
if totalmem > 1200 MB for 2 cycles then restart
if children > 250 then restart
check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/sshd start"
stop program "/etc/init.d/sshd stop"
if failed port 22 protocol ssh for 5 cycles then restart
if 5 restarts within 25 cycles then timeout
Output of "service httpd restart":
Stopping httpd: [FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
[FAILED]
Any help will be greatly appreciated.
Try to replace stop program with /usr/sbin/httpd -k stop. It work for me.
I had the same problem but /usr/sbin/httpd -k stop didn't seem to help since this still tries to look up the process id from the pid file.
I opted for stop program = "/usr/bin/killall httpd". I don't think this is very elegant (probably kills open requests) but it was the only way I could find to restart apache and have the pid file recreated by monit.
I think that monit is doing a restart as 'stop; start' and is not waiting for 'stop' to finish before starting a new process, and thus is deleting the pid file at an inappropriate time. At least, that's my conclusion after tinkering with all this.
I found a reference to someone who fixed this issue by making monit sleep after the 'stop' statement.
Personally, I found that replacing 'restart' with 'start' when the http server is down worked just fine.