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
