On 02/26/09 06:31, James Carlson wrote:
> 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.
>
>
I would like the -d to be more for developers. ( where the daemon runs
in the foreground and debug lines show up on screen, much like
in.routed -d which is not part of its SMF.
>> /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?
>
Good point. We will look into this.
>
>> 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.
>
>
Sangeeta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ilb-dev/attachments/20090226/f427df56/attachment.html>
