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 firstname.lastname@example.org http://linux.kernel.org/mailman/listinfo/mon