[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Monit starts, but isn't listening on port

From: Ted Fines
Subject: Monit starts, but isn't listening on port
Date: Thu, 15 Aug 2013 19:17:29 +0000

Problem: When Monit starts at boot on some systems, the monit process is started, but is not listening on port 2812.


I have 8 systems, all running Scientific Linux 6.4 (a free version of RHEL, like CentOS).


I had installed Monit 5.5.1 on each and had registered each with M/Monit.  Monit is started using upstart, using the included sample init script, which works great.


I recently rebooted them.  Monit started up on all of them, but on about one-half of the systems Monit is not listening on http port 2812, as defined in /etc/monitrc.  As a result when I try to view the system from M/Monit, I only get “Cannot connect to Monit – Connection refused.”


Below, you can see from my commands and the output that Monit is running but not listening on the port:

# status monit

monit start/running, process 1211

# ps -efwww | grep monit

root      1211     1  0 Aug14 ?        00:00:18 /usr/local/bin/monit -c /etc/monitrc

# telnet 2812


telnet: connect to address Connection refused

# lsof -i -P | grep monit



Here’s  /etc/monitrc:

# grep -v "^#" /etc/monitrc

set daemon  60              # check services at 1-minute intervals

set eventqueue basedir /var/monit slots 1000

set mmonit https://admin:address@hidden:8443/collector

set httpd port 2812 and

    use address  # Listen on main interface

    allow localhost       # allow localhost to connect to the server and

    allow        # allow M/Monit to connect to the server and

    allow admin:********        # require user 'admin' with password 'monit'


Now see how if I just stop & start monit again, it is listening on the port.  It is then also immediately available from M/Monit.

# stop monit && start monit && lsof -i -P | grep monit

monit stop/waiting

monit start/running, process 4217

monit      4217      root    5u  IPv4 315056      0t0  TCP (LISTEN)



This is problematic, having the monitoring agent think it is running correctly when it is not.  Anyone else run into this?  What did you do?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]