For reference, the documentation that describes "route monitor" is
these two paragraphs:
...
monitor Continuously report any changes to the routing
information base, routing lookup misses, or
suspected network partitionings.
...
The monitor sub-command has the following syntax:
route monitor [ -inet | -inet6 ]
...
and that's it so far as route(1m) is concerned.
So by likening "ilbdadm monitor" to "route monitor", I'm left
with very little knowledge about what will happen or to expect.
This is more a criticism of route(1m) but in light of that,
to judge what "ilbadm monitor" will do (or your "noone has
responses so..."), we really need more information.
Darren
On 25/02/09 09:02 AM, Sangeeta Misra wrote:
>
> Judging from the lack of response, I assume no one has any strong
> opinions on this. In that case I think what I will implement is
> "ilbadm monitor" which will be similar to route monitor and will not
> have a -f <filename > to it.
>
> Sangeeta
>
> On 02/24/09 13:44, Sangeeta Misra wrote:
>> Folks
>> Currently in our ILB code we have ( or are planning to have) two
>> things :
>>
>> o /usr/lib/inet/ilbd -d : The -d option runs the daemon in the
>> foreground and prints the debug messages on stderr or syslog ( this
>> is similar to in.routed -d option.) THis option is not usable under
>> SMF. So we assume that if the user is going to run ilbd with -d
>> option, he/she will disable ilb service via svcadm and simply
>> manually type "/usr/lib/inet/ilbd -d"
>>
>> /usr/sbin/ilbadm monitor : monitor filename : causes monitoring
>> information to be appended to file <filename>. use '-' for stdout.
>> This feature is run with /usr/lib/inet/ilbd running
>> in the background (started via svcadm enable <iilb service>. This
>> "monitor" option of ilbadm command can be used to monitor the ilbd
>> daemon's execution of events and communication with kernel. Note that
>> one does not require priviledged access to run the 'monitor" option.
>> By default the output of "ilbadm monitor" command will be appended to
>> a file. Events that would be recorded would be these:
>>
>> - ilbd sending notification to kernel about removing a server from a
>> virtual service ( this would result from ilbd using healthchecks to
>> find out that is server is non-responsive - sending of hc probe to a
>> server - diabling/enabling of a rule
>> - adding/deleting a server
>> - adding/removing a server group
>> - sending reset command to kernel upon starting - adding /removing a
>> rule to a server group - updating the persistent config file
>>
>> IMO although usr/sbin/ilbadm monitor feature is somewhat a duplicate
>> function of the ilb -d, it could point out problems in a different
>> way by pointing out what event *did not occur* that should have occured
>>
>>
>> My question is given we do have ilbd -d, do folks think it worthwhile
>> to have /usr/sbin/ilbadm monitor? Or should we skip the latter and
>> simply expand the ilbd -d implementation
>> to include 2 debug levels with the second one essentially causing
>> the events to be logged in syslog or screen
>>
>> Sangeeta
>> _______________________________________________
>> ilb-dev mailing list
>> ilb-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/ilb-dev
>
> _______________________________________________
> ilb-dev mailing list
> ilb-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ilb-dev
