On Tue, Jun 14, 2011 at 6:55 PM, Jim Trocki <troc...@gmail.com> wrote:
> On Mon, 13 Jun 2011, Nico Kadel-Garcia wrote:
>> I just ran into some confuson. I misunderstood the "mondir" setting in
>> a configuration, and presumed that it mon would search *all* the
>> listed directories for a specific monitor. The result was that I tried
>> stashing them, for separation from default monitors, in their own
>> directory.
> so if you have mondir which is a colon-separated list of directories, and
> a service definition specifies, say, "ping.monitor", it will search each
> of those directories for a ping.monitor and use the first one it finds.
> what was the behavior you were expecting? i don't understand.

As it turns out, I got multiply confused. The "mondir" setting is in
the manual page. It *does* describe a list of target directories to
search through. The problem is that the stable Debian mon package
reads init script settings from /etc/default/mon, and hands them as
command line arguments ot the "/usr/sbin/mon" program. This overrides
the contents of mon.cf: So where mon.cf said something like "mondir =
/usr/lib/mon/mon.d:/usr/local/lib/mon/mon.d" to allow host specific or
local monitors in /usr/local/lib/mon/mon.d/, the init script  wound up
forcing the use of /usr/lib/mon/mon.d

Edit /etc/devailt/mon, and suddenly it worked. Drove me *NUTS* finding that one.

>> It didn't work: not a huge surprise. What confused me was that the
>> missing monitors were simply "Untested", as opposed to being reported
>> "Missing". or "Unavailable". Would it seem appropriate and reasonable
>> to report missing minotirs as "Missing", to help avoid confusion
>> during restarts or confusion about monitors being unavailable from
>> some NFS shared resource?
> it does syslog that there's a problem with the config, i.e. it cannot
> find the monitor for a particular service, but nothing that would show
> up on the web page output or indicated via the client protocol. making a
> new state to indicate a config-related problem for a particular service
> is a good idea. there are a few different errors which could be indicated
> through that mechanism, beyond not finding the monitor in the mondir path.

Not being executable, I think, should be the test, rather than merely
not being present.

mon mailing list

Reply via email to