Sangeeta Misra writes: > 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"
Depending on when and why a user needs to use the "debug" option, I would consider just making a "config/debug" flag in SMF. It's a bit simpler to use that way, especially when you start putting more configuration there. Stay with "-d" if it's something only for the ilbd developers, but if it's something a customer may need to do, I think SMF integration is better. > /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: Is there any chance these might be better done with dtrace probes? > 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 I agree that there's some duplication here. Having good event logging features and debug dtrace probes would (I expect) remove much of the need for a separate active monitoring command. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
