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
