[Top][All Lists]

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

check file timestamp bug?

From: Alex Stewart
Subject: check file timestamp bug?
Date: Thu, 20 Sep 2007 22:23:21 -0400

Dear All,

monit is generally awesome (and documentation is really great btw) - but...

I am having a problem with monit that occurs in both v4.8.1 and v4.9
and the changelog (
appears to specifically state that the bug was fixed in v4.8:
("Removed a feature introduced in 4.7 which tested that a check-file,
check-directory or check-fifo actually refered to an existing object
of that type.  Monit should not require these file objects to exist at

Specifically I have a service that is mode manual (and in a separate
group) and hence the pid file for the service does not exist when
monit starts up (the group in question is not (and should not be)
started by default when the daemon starts up).  But although my
monitrc file passes the validation check, whenever I try to start
monit using it with the check file statement below included it exits
with the error:

Error: the path '/var/run/bfrt-monit/pid-files/' used in
the TIMESTAMP statement does not exist 'shutdown'

Although it seems pretty obvious what the problem is, to be sure I
tried substituting the pid file in the check file statement for a
random text file that does exist when monit is started and monit then
starts up just fine (just like it does if the check file statement is
commented out).

Given the wording of the changelog for v4.8 - and what would seem to
be logical behaviour (why should monit check for files that are mode
manual until the group has been started?) this would appear to be a

Am I missing something here or do people agree this is not desired
behaviour (if so what is the mechanism for filing a bug report)?


check file statement from monitrc file:
check file testMat_pidfile with path /var/run/bfrt-monit/pid-files/
   if changed timestamp 3 times within 12 cycles then exec
"/usr/local/bfrt-monit/scripts/nodeControl warn"
   mode manual
   group testGroup

reply via email to

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