On 25/02/09 12:00 PM, Sangeeta Misra wrote: > 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.
Ok, if the output is only sent to stdout, that's fine. >> 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 >> >
