Ethan Quach wrote:
> Alok Aggarwal wrote:
>>>> - Also, since this smf service is separate from the the 
>>>> auto-install smf service,
>>>> how would the output/error from this service be reported?  Will it 
>>>> be a separate
>>>> log file from the auto-install service?
>>>
>>> Its a separate log file.
>>
>> One of the things the AI client redesign proposes
>> is to consolidate all the installation related
>> logging into the auto-install service log. A central
>> log location like this helps users in not having to
>> look at multiple places to determine what's going on.
>>
>> It seems we're moving in the opposite direction by
>> creating another log file the user needs to keep
>> track of.
>
> As per our discussion on this at the meeting, I asked Liane
> about adding additional log file pointers to service definitions,
> and there currently isn't a proper way to do this.  In a service
> definition, there are tags to define doc links and manpage
> references that do get displayed with svcs -x, but these are
> metadata of the service, and not really fit for specifying the
> log file.  If we really want to be able to this, we could file an
> rfe.
>
>
> With the goal of having a single install log file in mind, we
> have a couple of options
>
> 1.  define the single install log file to be a separate file, and
> have each of the SMF service log files note where the install
> log is in their content.  This imposes an additional step for the
> user to -- look in smf log to get install log path, then go to
> actual install log -- but it keeps the functional separation of
> the services and provides for the proper granularity of restart
> and dependencies of the functionality we've defined.  Also
> when the rfe is fulfilled, we'll be able to note the separate log
> file in the svcs -x output.
>
> 2.  combine what we've functionally proposed as the manifest
> discovery service back into the auto-installer service.  We
> obviously lose benefits described above for #1.
>
>
> Please provides opinions/thoughts.  I would like closure on
> this by today if possible.
>
>
> thanks,
> -ethan
>
IMO, I think #1 is the better approach.  It allows the separation of
functionality, and the single log file.  The location of the log file
can also be documented, so, users would already know about it,
and not have to go through the SMF logs to find the path.  Additionally,
since the log file will exist in a standard location, users would know
about it after referencing it after a few times anyway.
Having a separate log file also has the advantage that if we
ever want to implement any of the features as non-SMF service, the 
application
can still write to that single well-known log file.

--Karen



Reply via email to