2012-10-01 15:28, 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.
Well, in my case I'm debugging (or seeing the progress of)
mounting the split-root filesystem components. Sometimes
things break in the BEs that I test, but I can repair stuff
by booting into the basic BE that works. Enabling/disabling
logs by a flag-file like this (or by a kernel option) is
IMHO much easier than doing it with SMF from another BE.
Likewise, it might be useful to put these log lines into
the SMF instance's log file (even if it never makes it from
/etc/svc/volatile to /var/log/svc on a particular broken
bootup, and the admin might never get to receiving a shell
to inspect these volatile logs in this instance's lifetime),
but having these lines (also) available via "dmesg" when
interactive login is possible is much more convenient for
an admin ;)
You might try setting the "logging" option for svc.startd.
Thanks, I'll take a look.
> 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.
This is in regard to a systems-initialization service which
works at the time where other services and networking and
stuff are not expected to be working, and specifically for
debugging this service when it also doesn't work (or to verify
that it does indeed). This all itself might be a bit off the
SMF ways ;)
> 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.
For regular services, I agree that writing to stdout/stderr
and letting SMF handle it is indeed proper and appropriate.
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.
Sad... I think in Linux all the options are exposed as readable
command-line parameters of some process (#1? #0? something...)
Thanks for info,
//Jim
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
