On Tue, Sep 01, 2009 at 11:50:17AM -0700, Jordan Brown wrote: > In the Brave New World of SMF, is it reasonable for a service to log by > writing messages to standard out or standard error, expecting SMF to > capture the output and dump it into the service log file? > > Argument for: > - Simple > - Automatically separated by service > - Automatically rotated
Actually, IIRC rotation is a problem because to do it right you need to replace the stdout/stderr file descriptors of the service's processes [and progeny that might still have them open, even if outside the service's process contract]. See below. > Arguments against: > - No automatic date/time stamping > - No standard filtering mechanism (e.g. by priority) > - Not routable (can't send high priority messages to different > destinations, or send to a log server) SMF could grow an option to set stdout/stderr to be a pipe, read messages from those pipes, and route to syslog (or whatever; adding timestamps if not already present). That'd be kinda neat, yet still problematic. See below. > - Might confuse utilities attempting to parse svc.startd messages from log > files Yes, but not likely. > - Might interact badly with log rotation, with service writing to a stale > log file after rotation See above. > - Can't merge messages from multiple services into one log (to make > sequence visible and have a single place to look for problems) Yes. SMF could: a) Add an option to SMF for automatic stdout/stderr -> syslog routing (see above). This could be done with a simple utility that can be executed from start method scripts, a standalone service, and a library for start methods that aren't scripts. One major downside of (a): broken pipes when that stdout/stderr -> syslog routing service restarts. Broken pipes -> SIGPIPE -> service restart. Oops. and/or b) discourage service logging to stdout/stderr. I'd say: (b), mostly because of the broken pipe issue. (A concept of "unreliable pipe" that works like /dev/null when there's no reader would be nice though, and would solve that problem.) Yes, I know, idmapd logs to stdout/stderr. That was a mistake, and partly it was because we didn't add observability interfaces. So my advice re: idmapd is this: 1) Add an idmap(1M) sub-command for asking idmapd its current status, including [optionally] _localized_ error messages; 2) Make idmapd log very little, if anything, to stdout/stderr. (1) is the key. Nico --
