Liane Praza wrote: > 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. > > I'll also note what I said to Ethan -- if these are separate services > which can fail separately, and their status is communicated by the > state of the service, it still makes sense to me to keep the data > about failure in the separate service logs. > > When I ask "what went wrong", it'd be nice not to have to wade through > a pile of unrelated "everything's OK" messages before determining the > root of the problem.
Thanks for bringing this up. This is another option we have here, and there's some merit to it since we've obviously defined the functionality as two separate services. There are other factors that we need to weigh in for this though, in that the entire install process, which could include multiple components, wants a common place to log. > > But, I haven't really kept up with your design, so will let you > evaluate the suggestion in light other requirements yourselves. > > (Something that occurs to me now is if you do decide to go with a > separate logfile, it'd be very very nice to still send a message to > the service log when a failure does occur that will send the service > to maintenance and hopefully how to resolve it, since that's usually > the information that's desired by an admin diagnosing an issue.) We'll make a best effort to do this without duplicating log data in two places. thanks, -ethan
