3

I cannot seem to get monit status or other CLI commands to work.


I've built monit v5.8 to run on a Raspberry Pi. I'm able to add services to be monitored, and the web interface can be accessed just fine, as I've set it up for public read-only access (it's a test server, not my final production setup, so not a big deal right now).

Problem is, when I run monit status while logged in as root I get:

# monit status
monit: cannot read status from the monit daemon

I also have monit started on boot via this /etc/inittab file entry:

mo:2345:respawn:/usr/local/bin/monit -Ic /etc/monitrc

I've verified that monit is running, and I'm getting email alerts anytime I either kill the monit process manually, or reboot my raspberry pi. So, next I check my monitrc file permissions to see which group is allowed access.

# ls -al /etc/monitrc
-rw------- 1 root root 2359 Aug 24 14:48 /etc/monitrc

Here's my relevant allow section of the control file.

set httpd port 80
    allow [omitted] readonly
    allow @root
    allow localhost
    allow 0.0.0.0/0.0.0.0

Also tried setting permissions on this file to 640 to allow group read permissions, but no matter what I try I either get the same error as noted above, or when the permissions are set to 640 I get:

# monit status
monit: The control file '/etc/monitrc' must have permissions no more than -rwx------ (0700); right now permissions are -rw-r----- (0640).

What am I missing here? I know that the httpd must be enabled, as that's the interface that the CLI uses to get information (or so I've read), so I've done that. And in terms of monit doing its monitoring job and sending email alerts, that's all working as well.


Here's my entire monitrc file - again, this is version v5.8, and it was build with both PAM and SSL support. The process runs under the root user:

# Global settings
set daemon 300
    with start delay 5
set logfile /var/log/monit.log
set pidfile /var/run/monit.pid
set idfile /var/run/.monit.id
set statefile /var/run/.monit.state

# Mail alerts
## Set the list of mail servers for alert delivery. Multiple servers may be
## specified using a comma separator. If the first mail server fails, Monit
# will use the second mail server in the list and so on. By default Monit uses
# port 25 - it is possible to override this with the PORT option.
#
set mailserver smtp.gmail.com port 587
               username [omitted] password [omitted]
               using tlsv1

## Send status and events to M/Monit (for more informations about M/Monit
## see http://mmonit.com/). By default Monit registers credentials with
## M/Monit so M/Monit can smoothly communicate back to Monit and you don't
## have to register Monit credentials manually in M/Monit. It is possible to
## disable credential registration using the commented out option below.
## Though, if safety is a concern we recommend instead using https when
## communicating with M/Monit and send credentials encrypted.
#
# set mmonit http://monit:[email protected]:8080/collector
#     # and register without credentials     # Don't register credentials
#
#
## Monit by default uses the following format for alerts if the the mail-format
## statement is missing::
set mail-format {
    from: [email protected]
 subject: $SERVICE $DESCRIPTION
 message: $EVENT

Service:     $SERVICE
Date:        $DATE
Action:      $ACTION
Host:        $HOST
Description: $DESCRIPTION

          Monit instance provided by chicagomeshnet.com
}

# Web status page
set httpd port 80
    allow [omitted] readonly
    allow @root
    allow localhost
    allow 0.0.0.0/0.0.0.0

## You can set alert recipients whom will receive alerts if/when a
## service defined in this file has errors. Alerts may be restricted on
## events by using a filter as in the second example below.
2
  • hi Jeff. did you solve it ? I am stuck on the same problem.
    – Massimo
    Sep 14, 2018 at 21:47
  • Don't think so. Was many years ago now.
    – jefflunt
    Sep 14, 2018 at 22:17

2 Answers 2

2

Try -v and -vv flags to increase status command verbosity. The next great tool to debug such problems is strace. Install it and run:

strace -efile -o trace.log monit status

Most likely you'll find the reason near the end of the log. If that doesn't help, run:

strace -f -o trace.log monit status

to see all the syscall-s the program and its children are making. Search for not found, connection refused, and such kind of errors.

1
  • 1
    +1 for the tip regarding strace, but it turned out not to lead me in a terribly useful direction in this case. Instead I copy/pasted the default http config section from the sample monitrc file, and just changed one thing at a time until I could get a working monit status to show up on the command line. I haven't yet got both a public-facing HTTP server and the CLI to work simultaneously, but at least I know I'm on the right track.
    – jefflunt
    Aug 24, 2014 at 23:55
0

For me to get it working I had to have a allow admin:monit rule.

set httpd port 2812 and
    use address 0.0.0.0
    allow 0.0.0.0/0
    allow localhost
    allow admin:monit
    allow guest:guest read-only

From this answer and http://dasunhegoda.com/what-why-how-monit/756/

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .