Ethan Quach wrote: > > > Jean McCormack wrote: >> Dave Miner wrote: >>> >>>> The use of virtual console was considered as a possibility if a >>>> more detailed progress >>>> is required. Preliminary investigation indicates that this >>>> currently is not in our microroot and would >>>> be too large to include there. >>>> >>> >>> Umm, please say more. We have long assumed that virtual consoles >>> would be a core part of the product when they were ready to go, as >>> they are on Linux distros, so I'm quite concerned about this. >> So we are back to considering a more detailed progress reported using >> the virtual console. >>> >>> BTW, it was somewhat implicit in the way you described it, but I'd >>> feel better if the explicit statement of a single log was made. I >>> would suggest that, if we're not using the SMF service log for this >>> (and we should be explicit about why we aren't), then I would expect >>> the location of the actual log to be recorded in the service log so >>> that there's some way of locating it other than "just knowing". >> OK. I'll make a more explicit statement that this log will be the >> only log on the client. > > Is the intent of the smf log file really to capture all > log/error/debug info for > everything that service could possibly run, or is it supposed to only > capture > log/error info for start/stop and other status from the service's > method script? > > I always thought it was the latter. Ethan,
I had thought that too, but I can't find anything on the greenline page that explicitely states this. I went looking at some log files. I have found several, including manifest-import that have messages that I cannot trace back to the method. So I asked someone in the smf group. The response was the following: "The start/stop methods' stdout and stderr are redirected to the log file. If the start method does fork and exec without changing these, the children will inherit this redirection." And this is considered legal. Jean > > -ethan > >> I have a question or three. If we make the only log the smf service >> log, will the users who have become used to looking in the standard >> install log area be confused? Is this even an issue? If so, would >> creating a sym link from the historical log file to the smf log file >> be appropriate? >> >> Jean >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
