[OpenIndiana-discuss] Debugging systems startup

[James Carlson]

Jim Klimov wrote:
> I want to inject some echo's into my SMF startup scripts to
> report about the progress of my systems startup (and possible
> problems). Actually I did that, and "echo... > /dev/console"
> if a special flag-file exists in the /etc/ filesystem.

SMF was actually designed to *avoid* that sort of mess, but I guess to
each his own.

You might try setting the "logging" option for svc.startd.

> 1) I wanted to make this mechanism more convenient by also
> logging the information if the kernel was booted with the
> "-m verbose" or "-v" option; how can a userland program
> query the options passed to OI kernel?

Looking at the source for svc.startd (usr/src/cmd/svc/startd.c), it
looks like that just sets an internal flag and isn't exposed to
applications.

> 2) Also, echoing to /dev/console does not put the messages
> into (local or remote) syslog files. What do the big boys
> do to properly report things to both syslog and console -
> issue the string writes twice (echo to console and pipe to
> "logger"), or is there some standard utility which can
> output the same logging output to several logging sinks,
> including the console and syslog, perhaps SNMP traps and
> whatnot else?

logger(1) is probably a better option than writing to /dev/console, but
you're already so far off the regular SMF path that it's hard to say.

It's by design that multiple services are started in parallel and that
each one writes to its own log file and that you don't get messages
unless something is wrong.

I suppose it'd be nice for someone to write a fancy SMF progress monitor
to quell the anxiety of those who can't see no news as good news (I
might be one of them ;-}), but I don't think reverting to a long
colorful "foobar ... OK" list as in the Linux world is the right way
forward.

> 3) Is there a good way to differentiate the "physical" and
> "serial" consoles, as to address and write to both of them
> if available? I know that I can write to /dev/term/a when
> running with a physical console, but I can't be certain in
> advance that on a particular system this port is plugged
> as a remote or serial console. And I'm not sure which TTY
> name addresses the physical screen when the kernel system
> console from the boot is attached to serial port.

/dev/wscons may work here ... but I certainly hesitate at the word "good."

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>