On Wed, 17 Jun 2009, 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.
#1 is better than the alternative. Especially given that the deficiency in SMF doesn't allow us to satisfy the requirement of following the svcs -x output for diagnostic purposes unless we go with a single service. So, I guess it boils down to the question of whether we want modularity by sacrificing serviceability a small amount. Alok
