On 02/25/09 11:41, Darren Reed wrote: > 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. I have listed what info ilbadm monitor will provide below. It will just provide it on screen, and when the user is done, he/she would simply hit Ctrl-C to get out of it.
> > 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 >
