|
Here’s more information on the
problem. We can tell that mon is automatically passing its standard option
to the alert as a getopts call within the alert that looks for “-s”
and a data field returns what the service name is that failed. So in the
example below, the alert, instead of taking “-s primary” and
assigning “primary” to that flag will instead use the service name
of “DHCP”. That sounds like expected behavior to me (and is
verified by mon’s man file entry). If, however, we change the line
below to read: alert
DHCPMonitor.alert –q primary There is nothing that is registered for
the “-q” option by getopts. We’ve tried “-x
primary” as well. If, however, we run the alert manually with that
option we do get something in the “-q” flag. BTW, the “_STANDARD_TIME_”
reference below is a macro we’re using with M4. That part works ok.
=) Any thoughts? Thanks, Tim From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Stringer Good morning, all. I was curious if anyone had any thoughts on the matter
below? Again, to summarize, we are unable to pass options in the Mon
configuration file to alerts. I do appreciate your time on the matter. Chris Stringer From: Chris
Stringer Hello, all. We have multiple locations with server pairs who check on
themselves as well as each other, and also a virtual "primary"
system. The scripts that we have written request that the
server to be checked be identified via an option, such as
"./DHCPMonitor.alert -q primary." Is it possible to pass
options to a called alert within the mon.m4 configuration? An example of what we're seeing is as follows: (From the mon.m4 file) service DHCP When options are passed to the monitor, everything works as
intended. This behavior is limited to passing options to the alert. I'd appreciate your time and thoughts on the matter. Chris Stringer |
_______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
