Darren Reed wrote: > As you'll note, this mentions standard output (stdout) and standard > error (stderr). This is not the same as what I'm referring to and > that is capturing text sent (directly) to the console. I'm fully > aware that it captures stdout and stderr already. Some applications, > be they daemons or otherwise, do output to the console and not > stdout/stderr.
"console" lost its meaning years ago... so old school :-) Back in the days when VAXen ruled the world, console had meaning as it was the place where the terminal used paper as a display. When IP came along, syslog was invented to allow other machines or random apps to write to the paper display. That paradigm is no longer valid. > Would you rather try and piece together the output saved > in 100 or more different log files or have it all in one? Absolutely not. The current bucket known as /var/adm/messages is a horror to deal with. It is much better to have real message ids (fma) and segregated service logs. This will become even more apparent as we continue to add services. The biggest trouble spot I see with people groking SMF is that you need to know the service state machine[*]. The second biggest tripping spot is that services never end, they just change state. This is far more useful than the old rc script world where you only had simple procedural programming. It is a big, big improvement over the previous generation. [I know, I know, some people don't like change... some people even enjoyed flipping the toggle switches to get the boot loader started :-)] [*] if you know the Sun Cluster resource state machine, it is very, very similar -- for good reason. -- richard
